The routes received by CEA from CEB is displayed as ASExt ospf type 5 LSA's.
The BGP MED metric carries the ospf metric.
Friday, December 17, 2010
OSPF as the PE-CE protocol
The routes received by CEA from CEB is displayed as ASExt ospf type 5 LSA's.
The BGP MED metric carries the ospf metric.
L3 VPN with PE-CE protocol as RIP and LDP as the transport protocol
Configuration on the PE:-
A:SRC_R1>config>service>vprn# info
----------------------------------------------
router-id 10.10.10.1
route-distinguisher 65100:10
auto-bind ldp
vrf-target target:65100:10
interface "r5" create
address 30.1.1.1/24
sap 1/1/4 create
exit
exit
rip
group "tor5"
neighbor "r5"
export "bgptorip"
exit
exit
exit
no shutdown
----------------------------------------------
Policy is required to export MPBGP routes received from the remote end to the CE routers:-
A:SRC_R1>config>router>policy-options# info
----------------------------------------------
policy-statement "bgptorip"
entry 10
from
protocol bgp-vpn
exit
to
protocol rip
exit
action accept
exit
exit
exit
----------------------------------------------
On the CE if the direct routes needs to be advertised then a policy is required on the CE also:-
ie from protocol direct
to rip
A:SRC_R2>config>router>ospf# show router 1 route-table
===============================================================================
Route Table (Service: 1)
===============================================================================
Dest Prefix Type Proto Age Pref
Next Hop[Interface Name] Metric
-------------------------------------------------------------------------------
10.10.10.5/32 Remote BGP VPN 00h47m48s 170
10.10.10.1 (tunneled) 0
10.10.10.6/32 Remote RIP 00h52m41s 100
35.1.1.2 2
30.1.1.0/24 Remote BGP VPN 01h31m55s 170
10.10.10.1 (tunneled) 0
35.1.1.0/24 Local Local 01h32m53s 0
r6 0
-------------------------------------------------------------------------------
No. of Routes: 4
===============================================================================
VPRN Ping:-
A:SRC_R1>config>service>vprn# oam vprn-trace 1 source 30.1.1.1 destination 35.1.1.2
TTL Seq Rcvd-on Reply-Path RTT
----------------------------------------------------------------------------
[Send request TTL: 1, Seq. 1.]
1 1 cpm In-Band 0.474ms
Node-Id 10.10.10.2
Requestor 10.10.10.1
Route: 35.1.1.0/24
Vpn Label: 131070 Metrics 0 Pref 170 Owner bgpVpn
Next Hops: [1] ldp tunnel
Route Targets: [1]: target:65100:10
Responder 10.10.10.2
Route: 35.1.1.0/24
Vpn Label: 0 Metrics 0 Pref 0 Owner local
Next Hops: [1] ifIdx 2 nextHopIp 35.1.1.2
[Send request TTL: 2, Seq. 1.]
2 1 sap:1/1/4 In-Band 1.47ms
Node-Id 10.10.10.2
Requestor 10.10.10.1
Route: 35.1.1.0/24
Vpn Label: 131070 Metrics 0 Pref 170 Owner bgpVpn
Next Hops: [1] ldp tunnel
Route Targets: [1]: target:65100:10
Responder 10.10.10.2
Route: 35.1.1.0/24
Vpn Label: 0 Metrics 0 Pref 0 Owner local
Next Hops: [1] ifIdx 2 nextHopIp 35.1.1.2
----------------------------------------------------------------------------
VPRN Ping:-
*A:SRC_R1# ping 35.1.1.1 router 1
PING 35.1.1.1 56 data bytes
64 bytes from 35.1.1.1: icmp_seq=1 ttl=64 time=0.905ms.
64 bytes from 35.1.1.1: icmp_seq=2 ttl=64 time=1.59ms.
64 bytes from 35.1.1.1: icmp_seq=3 ttl=64 time=1.57ms.
64 bytes from 35.1.1.1: icmp_seq=4 ttl=64 time=0.833ms.
64 bytes from 35.1.1.1: icmp_seq=5 ttl=64 time=1.47ms.
---- 35.1.1.1 PING Statistics ----
5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min = 0.833ms, avg = 1.27ms, max = 1.59ms, stddev = 0.333ms
*A:SRC_R1#
VPRN tracroute:-
*A:SRC_R1# traceroute 35.1.1.1 router 1
traceroute to 35.1.1.1, 30 hops max, 40 byte packets
1 35.1.1.1 (35.1.1.1) 1.12 ms 1.74 ms 1.43 ms
*A
A:SRC_R5# show router route-table
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix Type Proto Age Pref
Next Hop[Interface Name] Metric
-------------------------------------------------------------------------------
10.10.10.5/32 Local Local 01h37m56s 0
system 0
10.10.10.6/32 Remote RIP 00h24m41s 100
30.1.1.1 2
30.1.1.0/24 Local Local 01h01m25s 0
r1 0
35.1.1.0/24 Remote RIP 01h01m16s 100
30.1.1.1 2
-------------------------------------------------------------------------------
No. of Routes: 4
===============================================================================
*A:SRC_R5#
Normal pings and traceoute can be done from CE1 to CE2 to achieve this purpose.
Sunday, December 5, 2010
Using OSPF as a PE-CE protocol
OSPF LSA are not transported over the ip-vpn backbone.
The LSA are imported into ospf as AS externals the PE router acts as an ASBR in this case.The OSPF cost is transported as BGP MED attribute. OSPF routes are automatically imported into the MPBGP however a policy is required in the opposite direction ie from the MPBGP to ospf.
The LSA are imported into ospf as AS externals the PE router acts as an ASBR in this case.The OSPF cost is transported as BGP MED attribute. OSPF routes are automatically imported into the MPBGP however a policy is required in the opposite direction ie from the MPBGP to ospf.
Monday, November 29, 2010
MTU considerations
MTU defines the maximum size in bytes that a single unit of data that can be sent over a given link
If a packet cannot be sent over a given link ie if the size of the packet is more then the MTU which is defined then the packet is fragmented and the fragmented packets are reassembled at the other end.
Physical MTU:- This defines how large packets can be sent over the physical wire.
Service MTU:- This defines the service payload capabilities of the service ie how big packets that can be sent over the service.
SDP path MTU:- How large packets that can be sent over the sdp path.
IP-MTU command is used to configure the mtu of the vprn interface facing the CE router.
SDP MTU= Network port MTU-4 (mpls label)-4 (VC label)-14 null encapsulation/18 dot1q encapsulation
9212-(4+4+14)=9190
If a packet cannot be sent over a given link ie if the size of the packet is more then the MTU which is defined then the packet is fragmented and the fragmented packets are reassembled at the other end.
Physical MTU:- This defines how large packets can be sent over the physical wire.
Service MTU:- This defines the service payload capabilities of the service ie how big packets that can be sent over the service.
SDP path MTU:- How large packets that can be sent over the sdp path.
IP-MTU command is used to configure the mtu of the vprn interface facing the CE router.
SDP MTU= Network port MTU-4 (mpls label)-4 (VC label)-14 null encapsulation/18 dot1q encapsulation
9212-(4+4+14)=9190
Sunday, November 28, 2010
Route Target
To find out which VRF a partcular route will be associated with we need the assistance of Route Target.
In many cases the route distinguisher and route target may be of the same value but they should never be equated to be similar.
The import route target of the receiving PE should match the export route target of the originating PE.
There can be one route distinguisher per route but there can be multiple route targets per route.
In many cases the route distinguisher and route target may be of the same value but they should never be equated to be similar.
The import route target of the receiving PE should match the export route target of the originating PE.
There can be one route distinguisher per route but there can be multiple route targets per route.
L3 VPN addressing
In the case of L3 VPN a new structure of addressing is established, the customer routes are carried by the BGP, however if normal bgp was used then the customer CE routes will not be carried if overlapping address is used, as bgp will intall only one route for a particular destination ie the best route will be installed in the routing table however in L3 VPN the same PE might have two different VRF which might have the same destination prefix.
Hence a new address structure is used which is known as VPN-IPv4 address.
In this case to make the ipv4 address globally unique a 64 bit route distinguisher is added on the ipv4 address
Route Distinguisher+ip v4 address = vpn-ipv4 address
The purpose of the route distinguisher is to ensure that the ipv4 address is globally unique.
A route distinguisher consists of 64 bits an ipv4 address consists of 32 bits hence the full vpn-ipv4 address is 64+32=96 bits.
In the case of Type 0 the administrator subfield contains the AS number, this should ideally be a public AS number, use of private AS number is discouraged.
Assigned number is the number assigned by the service provider.
In the case of Type 1
The administrator subfield must contain an ip address use of public ip address is preferred, assigned number is again assigned by the service provider.
It makes ample sense to assign the same RD to same VRF in different sites.
VPN-ipv4 addresses are only visible on the control plane of the provider network.
By default BGP will not transmit vpn-ipv4 routes as it is only designed to transmit ipv4 routes.
Hence to transmit vpn-ipv4 routes multiprotocol extensions of bgp must be enabled this feature is know mp-bgp.
Full mesh or equivalent of mpbgp is required to achieve this purpose.
PE to PE route exchange:-
Hence a new address structure is used which is known as VPN-IPv4 address.
In this case to make the ipv4 address globally unique a 64 bit route distinguisher is added on the ipv4 address
Route Distinguisher+ip v4 address = vpn-ipv4 address
The purpose of the route distinguisher is to ensure that the ipv4 address is globally unique.
A route distinguisher consists of 64 bits an ipv4 address consists of 32 bits hence the full vpn-ipv4 address is 64+32=96 bits.
Assigned number is the number assigned by the service provider.
In the case of Type 1
The administrator subfield must contain an ip address use of public ip address is preferred, assigned number is again assigned by the service provider.
It makes ample sense to assign the same RD to same VRF in different sites.
VPN-ipv4 addresses are only visible on the control plane of the provider network.
By default BGP will not transmit vpn-ipv4 routes as it is only designed to transmit ipv4 routes.
Hence to transmit vpn-ipv4 routes multiprotocol extensions of bgp must be enabled this feature is know mp-bgp.
Full mesh or equivalent of mpbgp is required to achieve this purpose.
PE to PE route exchange:-
The vpn label ie the inner label is exchanged with the help of mp-bgp.
T-LDP is never used for label signalling in this case.
PE-CE routes that are supported
The PE-CE routes that are supported are
Static Routes
RIP
OSPF
BGP
Each PE will have provider core routes and the VRF routing table associated to each customer.
Static Routes
RIP
OSPF
BGP
Each PE will have provider core routes and the VRF routing table associated to each customer.
Subscribe to:
Posts (Atom)