Any Transport Over MPLS (AToM)Any Transport over MPLS (AToM) will transport layer 2 frames over a MPLS (Multiprotocol Label Switching) network. This will allow service providers to connect layer 2 networks of customers transparently by using their MPLS backbone. AToM can transport the following: ATM AAL5 ATM Cell Relay Ethernet Frame Relay PPP HDLCI will give you an example how to configure AToM to transport Ethernet over the MPLS backbone, we will use the following topology to do this:

Above you see a small MPLS backbone that consists of the PE1, P and PE2 router. This ISP only has one customer that has a HQ and Branch. The customer wants to have the HQ and Branch router to be in the same layer 2 segment.ConfigurationFirst we will enable OSPF to advertise the loopback interfaces, these will be used as the router ID for MPLS LDP:PE1(config)#router ospf 1PE1(config-router)#network 192.168.12.0 0.0.0.255 area 0PE1(config-router)#network 1.1.1.1 0.0.0.0 area 0P(config)#router ospf 1P(config-router)#network 192.168.12.0 0.0.0.255 area 0P(config-router)#network 192.168.23.0 0.0.0.255 area 0P(config-router)#network 2.2.2.2 0.0.0.0 area 0PE2(config)#router ospf 1PE2(config-router)#network 192.168.23.0 0.0.0.255 area 0PE2(config-router)#network 3.3.3.3 0.0.0.0 area 0Now we will enable MPLS LDP on the interfaces connecting the PE1, P and PE2 routers:PE1(config)#interface fastEthernet 0/1PE1(config-if)#mpls ipP(config)#interface fastEthernet 0/0P(config-if)#mpls ip

P(config)#interface fastEthernet 0/1P(config-if)#mpls ip PE2(config)#interface fastEthernet 0/0PE2(config-if)#mpls ipJust to be sure lets verify that we have LDP neighbors:P#show mpls ldp neighbor | include Peer Peer LDP Ident: 1.1.1.1:0; Local LDP Ident 2.2.2.2:0 Peer LDP Ident: 3.3.3.3:0; Local LDP Ident 2.2.2.2:0That seems to be the case! Now we can configure AToM so that the HQ and Branch router are able to reach each other:PE1(config)#interface fastEthernet 0/0PE1(config-if)#xconnect 3.3.3.3 13 encapsulation mplsPE2(config)#interface fastEthernet 0/1PE2(config-if)#xconnect 1.1.1.1 13 encapsulation mplsWe need to use the xconnect command between PE1 and PE2. The VC ID (13) has to be the same on both routers.VerificationFirst we will check our LDP peers:PE1#show mpls ldp neighbor 3.3.3.3 Peer LDP Ident: 3.3.3.3:0; Local LDP Ident 1.1.1.1:0TCP connection: 3.3.3.3.64567 - 1.1.1.1.646State: Oper; Msgs sent/rcvd: 15/15; DownstreamUp time: 00:05:19LDP discovery sources: Targeted Hello 1.1.1.1 -> 3.3.3.3, active, passive Addresses bound to peer LDP Ident: 192.168.23.3 3.3.3.3 PE2#show mpls ldp neighbor 1.1.1.1 Peer LDP Ident: 1.1.1.1:0; Local LDP Ident 3.3.3.3:0TCP connection: 1.1.1.1.646 - 3.3.3.3.64567State: Oper; Msgs sent/rcvd: 15/15; DownstreamUp time: 00:05:38LDP discovery sources: Targeted Hello 3.3.3.3 -> 1.1.1.1, active, passive Addresses bound to peer LDP Ident: 192.168.12.1 1.1.1.1 PE1 and PE2 are LDP neighbors, now well verify that they are transporting our Ethernet traffic:PE1#show mpls l2transport binding Destination Address: 3.3.3.3, VC ID: 13 Local Label: 19 Cbit: 1, VC Type: Ethernet, GroupID: 0 MTU: 1500, Interface Desc: n/a VCCV: CC Type: CW [1], RA [2] CV Type: LSPV [2] Remote Label: 19 Cbit: 1, VC Type: Ethernet, GroupID: 0 MTU: 1500, Interface Desc: n/a VCCV: CC Type: CW [1], RA [2] CV Type: LSPV [2]PE2#show mpls l2transport binding Destination Address: 1.1.1.1, VC ID: 13 Local Label: 19 Cbit: 1, VC Type: Ethernet, GroupID: 0 MTU: 1500, Interface Desc: n/a VCCV: CC Type: CW [1], RA [2] CV Type: LSPV [2] Remote Label: 19 Cbit: 1, VC Type: Ethernet, GroupID: 0 MTU: 1500, Interface Desc: n/a VCCV: CC Type: CW [1], RA [2] CV Type: LSPV [2]A label has been assigned to this virtual circuit, you can see it says Ethernet. Theres another useful command that lets us check the AToM configuration:PE1#show mpls l2transport vc

Local intf Local circuit Dest address VC ID Status ------------- -------------------------- --------------- ---------- ----------Fa0/0 Ethernet 3.3.3.3 13 UPPE2#show mpls l2transport vc

Local intf Local circuit Dest address VC ID Status ------------- -------------------------- --------------- ---------- ----------Fa0/1 Ethernet 1.1.1.1 13 UP Above you have a nice overview with the interfaces, transport type, virtual circuit ID and the status. Everything is looking good to lets give it a test drive:HQ#ping 172.16.1.2

Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds:!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 16/20/40 msOur ping is successful, we can verify the number of packets that have been sent as following:PE1#show mpls l2transport vc detail Local interface: Fa0/0 up, line protocol up, Ethernet up Destination address: 3.3.3.3, VC ID: 13, VC status: up Next hop: 192.168.12.2 Output interface: Fa0/1, imposed label stack {17 19} Create time: 00:09:46, last status change time: 00:09:41 Signaling protocol: LDP, peer 3.3.3.3:0 up MPLS VC labels: local 19, remote 19 Group ID: local 0, remote 0 MTU: local 1500, remote 1500 Remote interface description: Sequencing: receive disabled, send disabled VC statistics: packet totals: receive 84, send 83 byte totals: receive 9445, send 9045 packet drops: receive 0, seq error 0, send 0

You are here: Home BGP Cisco CCIE R&S BGP Prevent Transit ASBGP Prevent Transit ASBy default BGP will advertise all prefixes to EBGP (External BGP) neighbors. This means that if you are multi-homed (connected to two or more ISPs) that you might become a transit AS. Let me show you an example:

R1 is connected to ISP1 and ISP2 and each router is in a different AS (Autonomous System). Since R1 is multi-homed its possible that the ISPs will use R1 to reach each other. In order to prevent this well have to ensure that R1 only advertises prefixes from its own autonomous system.As far as I know there are 4 methods how you can prevent becoming a transit AS: Filter-list with AS PATH access-list. No-Export Community. Prefix-list Filtering Distribute-list FilteringPrefix-lists or distribute-lists will work but its not a very scalable solution if you have thousands of prefixes in your BGP table. The filter-list and no-export community work very well since you only have to configure them once and it will not matter if new prefixes show up. First well configure BGP on each router:R1(config)#router bgp 1R1(config-router)#neighbor 192.168.12.2 remote-as 2R1(config-router)#neighbor 192.168.13.3 remote-as 3ISP1(config)#router bgp 2ISP1(config-router)#neighbor 192.168.12.1 remote-as 1ISP2(config)#router bgp 3ISP2(config-router)#neighbor 192.168.13.1 remote-as 1The commands above will configure EBGP (External BGP) between R1 ISP1 and R1 ISP2. To make sure we have something to look at, Ill advertise the loopback interfaces in BGP on each router:R1(config)#router bgp 1R1(config-router)#network 1.1.1.0 mask 255.255.255.0ISP1(config)#router bgp 2ISP1(config-router)#network 2.2.2.0 mask 255.255.255.0ISP2(config)#router bgp 3ISP2(config-router)#network 3.3.3.0 mask 255.255.255.0With the networks advertised, lets take a look at the BGP table of ISP1 and ISP2 to see what they have learned:ISP1#show ip bgp BGP table version is 4, local router ID is 11.11.11.11Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S StaleOrigin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path*> 1.1.1.0/24 192.168.12.1 0 0 1 i*> 2.2.2.0/24 0.0.0.0 0 32768 i*> 3.3.3.0/24 192.168.12.1 0 1 3 iISP2#show ip bgp BGP table version is 4, local router ID is 33.33.33.33Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S StaleOrigin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path*> 1.1.1.0/24 192.168.13.1 0 0 1 i*> 2.2.2.0/24 192.168.13.1 0 1 2 i*> 3.3.3.0/24 0.0.0.0 0 32768 iThe ISP routers have learned about each other networks and they will use R1 as the next hop. We now have everything in place to play with the different filtering techniques.Filter-list with AS PATH access-listUsing an filter-list with the AS PATH access-list is probably the most convenient solution. It will ensure that you will always only advertise prefixes from your own autonomous system. Heres how to do it:R1(config)#ip as-path access-list 1 permit ^$

R1(config-router)#neighbor 192.168.12.2 filter-list 1 outR1(config-router)#neighbor 192.168.13.3 filter-list 1 outThe ^$ regular expression ensures that we will only advertise locally originated prefixes. Well have to apply this filter to both ISPs.Keep in mind that BGP is slowif you are doing labs, its best to speed things up with clear ip bgp *Lets verify our configuration:R1#show ip bgp BGP table version is 4, local router ID is 22.22.22.22Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S StaleOrigin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path*> 1.1.1.0/24 0.0.0.0 0 32768 i*> 2.2.2.0/24 192.168.12.2 0 0 2 i*> 3.3.3.0/24 192.168.13.3 0 0 3 iR1 still knows about the prefixes from the ISP routers. What about ISP1 and ISP2?ISP1#show ip bgp BGP table version is 7, local router ID is 11.11.11.11Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S StaleOrigin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path*> 1.1.1.0/24 192.168.12.1 0 0 1 i*> 2.2.2.0/24 0.0.0.0 0 32768 iISP2#show ip bgp BGP table version is 7, local router ID is 33.33.33.33Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S StaleOrigin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path*> 1.1.1.0/24 192.168.13.1 0 0 1 i*> 3.3.3.0/24 0.0.0.0 0 32768 iISP1 and ISP2 only know about the 1.1.1.0 /24 network. Excellent, we are no longer a transit AS! On to the next methodNo-Export CommunityUsing the no-export community will also work pretty well. We will configure R1 so that prefixes from the ISP routers will be tagged with the no-export community. This ensures that the prefixes from those routers will be known within AS 1 but wont be advertised to other routers.R1(config)#route-map NO-EXPORTR1(config-route-map)#set community no-export

R1(config)#router bgp 1R1(config-router)#neighbor 192.168.12.2 route-map NO-EXPORT inR1(config-router)#neighbor 192.168.13.3 route-map NO-EXPORT inIm only using one router in AS 1, if you have other routers and are running IBGP (Internal BGP) then dont forget to send communities to those routers with the neighbor send-community command.Lets see what ISP1 and ISP2 think about our configuration:ISP1#show ip bgp BGP table version is 11, local router ID is 11.11.11.11Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S StaleOrigin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path*> 1.1.1.0/24 192.168.12.1 0 0 1 i*> 2.2.2.0/24 0.0.0.0 0 32768 iISP2#show ip bgp BGP table version is 11, local router ID is 33.33.33.33Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S StaleOrigin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path*> 1.1.1.0/24 192.168.13.1 0 0 1 i*> 3.3.3.0/24 0.0.0.0 0 32768 iThey only know about network 1.1.1.0 /24. Onto the next method!Prefix-List FilteringUsing a prefix-list we can determine what prefixes are advertised to our BGP neighbors. This works fine but its not a good solution to prevent becoming a transit AS. Each time you add new prefixes youll have to reconfigure the prefix-list. Anyway let me show you how it works:R1(config)#ip prefix-list NO-TRANSIT permit 1.1.1.0/24

R1(config-router)#neighbor 192.168.12.2 prefix-list NO-TRANSIT out R1(config-router)#neighbor 192.168.13.3 prefix-list NO-TRANSIT outThe prefix-list above will only advertise 1.1.1.0 /24 to the ISP routers. Lets verify the configuration:ISP1#show ip bgp BGP table version is 17, local router ID is 11.11.11.11Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S StaleOrigin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path*> 1.1.1.0/24 192.168.12.1 0 0 1 i*> 2.2.2.0/24 0.0.0.0 0 32768 iISP2#show ip bgp BGP table version is 17, local router ID is 33.33.33.33Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S StaleOrigin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path*> 1.1.1.0/24 192.168.13.1 0 0 1 i*> 3.3.3.0/24 0.0.0.0 0 32768 iThe prefix-list is working as it should, onto the last exercise!Distribute-list FilteringThis method is similar to using the prefix-list but this time well use an access-list.R1(config)#ip access-list standard NO-TRANSITR1(config-std-nacl)#permit 1.1.1.0 0.0.0.255

R1(config-router)#neighbor 192.168.12.2 distribute-list NO-TRANSIT outR1(config-router)#neighbor 192.168.13.3 distribute-list NO-TRANSIT outTime to check the ISPs:ISP1#show ip bgp BGP table version is 23, local router ID is 11.11.11.11Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S StaleOrigin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path*> 1.1.1.0/24 192.168.12.1 0 0 1 i*> 2.2.2.0/24 0.0.0.0 0 32768 iISP2#show ip bgp BGP table version is 23, local router ID is 33.33.33.33Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S StaleOrigin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path*> 1.1.1.0/24 192.168.13.1 0 0 1 i*> 3.3.3.0/24 0.0.0.0 0 32768 iThats all there is to it. I hope this has been helpful for you, if you know of any other methods to prevent becoming a BGP transit AS please leave a comment!

MPLS VPN Configuration ExampleIn this article Im going to walk you through the configuration of a small MPLS VPN network using MP-BGP (Multi-Protocol Border Gateway Protocol) and only two VRFs. I will be using the following topology for this:

Above you see 3 routers connected to each other. R1 and R3 each have two loopback interfaces. The loopback 0 interface will be used to establish a BGP neighbor adjacency, the loopback 1 interfaces will be in two different VRFs called blue and red.First well configure OSPF so that R1 and R3 can reach each others loopback 0 interface:R1(config)#router ospf 1R1(config-router)#network 192.168.12.1 0.0.0.0 area 0R1(config-router)#network 1.1.1.1 0.0.0.0 area 0R2(config)#router ospf 1R2(config-router)#network 192.168.12.2 0.0.0.0 area 0R2(config-router)#network 192.168.23.2 0.0.0.0 area 0R3(config)#router ospf 1R3(config-router)#network 192.168.23.3 0.0.0.0 area 0R3(config-router)#network 3.3.3.3 0.0.0.0 area 0Make sure you configure a /32 network mask on the loopback 0 interfaces. If you dont, youll run into issues with MPLS because OSPF by default will always advertise a loopback interface as /32.Well continue by configuring MPLS on the interfaces of all routers:R1(config)#interface fastEthernet 0/0R1(config-if)#mpls ipR2(config)#interface fastEthernet 0/0R2(config-if)#mpls ip

R2(config)#interface fastEthernet 1/0R2(config-if)#mpls ip R3(config)#interface fastEthernet 0/0R3(config-if)#mpls ipEnabling MPLS is simple enough, lets verify that we have neighbors:R2#show mpls ldp neighbor Peer LDP Ident: 1.1.1.1:0; Local LDP Ident 192.168.23.2:0TCP connection: 1.1.1.1.646 - 192.168.23.2.35345State: Oper; Msgs sent/rcvd: 7/7; DownstreamUp time: 00:00:21LDP discovery sources: FastEthernet0/0, Src IP addr: 192.168.12.1 Addresses bound to peer LDP Ident: 192.168.12.1 1.1.1.1 Peer LDP Ident: 3.3.3.3:0; Local LDP Ident 192.168.23.2:0TCP connection: 3.3.3.3.646 - 192.168.23.2.45741State: Oper; Msgs sent/rcvd: 7/7; DownstreamUp time: 00:00:03LDP discovery sources: FastEthernet1/0, Src IP addr: 192.168.23.3 Addresses bound to peer LDP Ident: 192.168.23.3 3.3.3.3 Fair enough, R2 has two MPLS LDP neighbors. If you are interested, you can take a look at the labels that are in use:R1#show mpls forwarding-table Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 16 17 3.3.3.3/32 0 Fa0/0 192.168.12.2 17 Pop tag 192.168.23.0/24 0 Fa0/0 192.168.12.2R2#show mpls forwarding-table Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 16 Pop tag 1.1.1.1/32 0 Fa0/0 192.168.12.1 17 Pop tag 3.3.3.3/32 0 Fa1/0 192.168.23.3R3#show mpls forwarding-table Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 16 Pop tag 192.168.12.0/24 0 Fa0/0 192.168.23.2 17 16 1.1.1.1/32 0 Fa0/0 192.168.23.2With MPLS running and labels being advertised, we can continue and create the two VRFs:R1(config)#ip vrf BLUER1(config-vrf)#rd 100:1R1(config-vrf)#route-target export 100:1R1(config-vrf)#route-target import 100:3VRF Blue will be created on R1. We will use RD (Route Distinguisher) 100:1 for VRF blue and 100:3 for VRF red . Now we can create a new loopback and add it to the VRF:R1(config)#interface loopback1R1(config-if)#ip vrf forwarding BLUER1(config-if)#ip address 11.11.11.11 255.255.255.0Loopback 1 has an IP address and is added to VRF blue. Now lets do the same thing on R3:R3(config)#ip vrf REDR3(config-vrf)#rd 100:3R3(config-vrf)#route-target export 100:3R3(config-vrf)#route-target import 100:1R3(config)#interface loopback 1R3(config-if)#ip vrf forwarding REDR3(config-if)#ip address 33.33.33.33 255.255.255.0On R3 well create VRF red and use 100:3 as the RD. Now we can configure BGP on both routers:R1(config)#router bgp 13R1(config-router)#neighbor 3.3.3.3 remote-as 13R1(config-router)#neighbor 3.3.3.3 update-source loopback 0R1(config-router)#address-family vpnv4 R1(config-router-af)#neighbor 3.3.3.3 activate R1(config-router-af)#neighbor 3.3.3.3 send-community extended R1(config-router-af)#exitR1(config-router)#address-family ipv4 unicast vrf BLUER1(config-router-af)#redistribute connected R3(config)#router bgp 13R3(config-router)#neighbor 1.1.1.1 remote-as 13R3(config-router)#neighbor 1.1.1.1 update-source loopback 0R3(config-router)#address-family vpnv4 R3(config-router-af)#neighbor 1.1.1.1 activate R3(config-router-af)#neighbor 1.1.1.1 send-community extended R3(config-router-af)#exitR3(config-router)#address-family ipv4 unicast vrf REDR3(config-router-af)#redistribute connectedAbove we configured a couple of things for BGP: First we need to establish a BGP neighbor adjacency, I did this between the loopback 0 interfaces of R1 and R3. Secondly we need to enable the VPNv4 address family on both routers and ensure that they send the extended format communities to each other. Last but not least, redistribute the loopback 1 interfaces into the VRF on both routers.Lets verify our configuration:R1#show bgp vpnv4 unicast all summary BGP router identifier 11.11.11.11, local AS number 13BGP table version is 3, main routing table version 32 network entries using 274 bytes of memory2 path entries using 136 bytes of memory2/1 BGP path/bestpath attribute entries using 248 bytes of memory1 BGP extended community entries using 24 bytes of memory0 BGP route-map cache entries using 0 bytes of memory0 BGP filter-list cache entries using 0 bytes of memoryBGP using 682 total bytes of memoryBGP activity 2/0 prefixes, 2/0 paths, scan interval 15 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd3.3.3.3 4 13 7 5 3 0 0 00:02:29 1R3#show bgp vpnv4 unicast all summary BGP router identifier 3.3.3.3, local AS number 13BGP table version is 5, main routing table version 53 network entries using 411 bytes of memory3 path entries using 204 bytes of memory3/2 BGP path/bestpath attribute entries using 372 bytes of memory2 BGP extended community entries using 48 bytes of memory0 BGP route-map cache entries using 0 bytes of memory0 BGP filter-list cache entries using 0 bytes of memoryBGP using 1035 total bytes of memoryBGP activity 7/4 prefixes, 7/4 paths, scan interval 15 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd1.1.1.1 4 13 25 26 5 0 0 00:04:44 1R1 and R3 have received a prefix from each other, lets find out what they got:R1#show bgp vpnv4 unicast all BGP table version is 13, local router ID is 11.11.11.11Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S StaleOrigin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight PathRoute Distinguisher: 100:1 (default for vrf BLUE)*> 11.11.11.0/24 0.0.0.0 0 32768 ?*>i33.33.33.0/24 3.3.3.3 0 100 0 ?Route Distinguisher: 100:3*>i33.33.33.0/24 3.3.3.3 0 100 0 ?R3#show bgp vpnv4 unicast all BGP table version is 5, local router ID is 3.3.3.3Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S StaleOrigin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight PathRoute Distinguisher: 100:1*>i11.11.11.0/24 1.1.1.1 0 100 0 ?Route Distinguisher: 100:3 (default for vrf RED)*>i11.11.11.0/24 1.1.1.1 0 100 0 ?*> 33.33.33.0/24 0.0.0.0 0 32768 ?The routers learned about each others networks, lets try if they can ping each other:R1#ping vrf BLUE 33.33.33.33 source loopback 1

Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 33.33.33.33, timeout is 2 seconds:Packet sent with a source address of 11.11.11.11 !!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 msThere you go, we have reachability between the two routers. Dont forget to specify the VRF if you try to ping between R1 and R3. The example above can be easily modified if you want to test OSPF, EIGRP or RIP. Just replace the redistribute connected with the routing protocol you want.

MPLS LDP Label Filtering Example Posted on May 7, 2013 by Rene Molenaar in CCIE R&S, Cisco, MPLS Once you enable MPLS on the interfaces between the routers and LDP neighbor adjacencies have been formed, a label will be advertised for each network. With LDP however we can configure filters to decide what networks should get a label and which ones shouldnt be tagged. Ill use the following topology to demonstrate this:

Above we have 3 routers and each router has 2 loopback interfaces so that we have plenty of networks to play with. Before we enable MPLS well configure OSPF so that all networks are advertised:R1,R2,R3:(config)#router ospf 1(config-router)#network 0.0.0.0 255.255.255.255 area 0Well do this the easy way and activate OSPF on all interfaces. Now lets enable MPLS on the FastEthernet interfaces:R1(config)#interface fastEthernet 0/0R1(config-if)#mpls ipR2(config)#interface fastEthernet 0/0R2(config-if)#mpls ipR2(config-if)#exitR2(config)#interface fastEthernet 0/1R2(config-if)#mpls ip R3(config)#interface fastEthernet 0/0R3(config-if)#mpls ipLets check if we have LDP neighbors:R2#show mpls ldp neighbor | include Peer Peer LDP Ident: 11.11.11.11:0; Local LDP Ident 22.22.22.22:0 Peer LDP Ident: 33.33.33.33:0; Local LDP Ident 22.22.22.22:0So far so good, now lets take a look at the LDP labels that have been generated:R1#show mpls forwarding-table Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 16 Pop tag 2.2.2.2/32 0 Fa0/0 192.168.12.2 17 17 33.33.33.33/32 0 Fa0/0 192.168.12.2 18 18 3.3.3.3/32 0 Fa0/0 192.168.12.2 19 Pop tag 22.22.22.22/32 0 Fa0/0 192.168.12.2 20 Pop tag 192.168.23.0/24 0 Fa0/0 192.168.12.2 R2#show mpls forwarding-table Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 16 Pop tag 1.1.1.1/32 0 Fa0/0 192.168.12.1 17 Pop tag 33.33.33.33/32 0 Fa0/1 192.168.23.3 18 Pop tag 3.3.3.3/32 0 Fa0/1 192.168.23.3 19 Pop tag 11.11.11.11/32 0 Fa0/0 192.168.12.1 R3#show mpls forwarding-table Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 16 Pop tag 192.168.12.0/24 0 Fa0/0 192.168.23.2 17 16 1.1.1.1/32 0 Fa0/0 192.168.23.2 18 Pop tag 2.2.2.2/32 0 Fa0/0 192.168.23.2 19 Pop tag 22.22.22.22/32 0 Fa0/0 192.168.23.2 20 19 11.11.11.11/32 0 Fa0/0 192.168.23.2For all networks a label has been generated by LDP. Now lets configure filtering so that we only generate labels for the loopback 0 interfaces. This is how you do it:R1(config)#access-list 1 permit 1.1.1.1 0.0.0.0R1(config)#no mpls ldp advertise-labelsR1(config)#mpls ldp advertise-labels for 1R2(config)#access-list 1 permit 2.2.2.2 0.0.0.0R2(config)#no mpls ldp advertise-labelsR2(config)#mpls ldp advertise-labels for 1R3(config)#access-list 1 permit 3.3.3.3 0.0.0.0R3(config)#no mpls ldp advertise-labelsR3(config)#mpls ldp advertise-labels for 1First use no mpls ldp advertise-labels to disable the advertisement of all labels. Secondly use the mpls ldp advertise-labels for command and refer to an access-list or prefix-list to choose what networks should have a label.Be careful, if you forget to use the no mpls ldp advertise-labels command you will discover that LDP is STILL advertising a label for each networkLets verify our work:R1#show mpls forwarding-table Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 16 Pop tag 2.2.2.2/32 0 Fa0/0 192.168.12.2 17 Untagged 33.33.33.33/32 0 Fa0/0 192.168.12.2 18 Untagged 3.3.3.3/32 0 Fa0/0 192.168.12.2 19 Untagged 22.22.22.22/32 0 Fa0/0 192.168.12.2 20 Untagged 192.168.23.0/24 0 Fa0/0 192.168.12.2R2#show mpls forwarding-table Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 16 Pop tag 1.1.1.1/32 0 Fa0/0 192.168.12.1 17 Untagged 33.33.33.33/32 0 Fa0/1 192.168.23.3 18 Pop tag 3.3.3.3/32 0 Fa0/1 192.168.23.3 19 Untagged 11.11.11.11/32 0 Fa0/0 192.168.12.1R3#show mpls forwarding-table Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 16 Untagged 192.168.12.0/24 0 Fa0/0 192.168.23.2 17 Untagged 1.1.1.1/32 0 Fa0/0 192.168.23.2 18 Pop tag 2.2.2.2/32 0 Fa0/0 192.168.23.2 19 Untagged 22.22.22.22/32 0 Fa0/0 192.168.23.2 20 Untagged 11.11.11.11/32 0 Fa0/0 192.168.23.2 Above you can see that only network 1.1.1.1/32, 2.2.2.2/32 and 3.3.3.3/32 now have a label when advertised to a LDP neighbor. Thats all I wanted to show you, if you have any questions feel free to leave a comment!

Introduction to Redistribution Posted on February 21, 2013 by Rene Molenaar in CCNP ROUTE, Cisco, IP Routing Most networks you encounter will probably only run a single routing protocol like OSPF or EIGRP. Maybe you find some old small networks that are still running RIP that need migration to OSPF or EIGRP. What if you have a company that is running OSPF and you just bought another company and their network is running EIGRP?Its possible that we have multiple routing protocols on our network and well need some method to exchange routing information between the different protocols. This is called redistribution. Well look into some of the issues that we encounter. What are we going to do with our metrics? OSPF uses cost and EIGRP uses K-values and they are not compatible with each other.RIP uses hop count.Redistribution also adds another problem. If you import routing information from one routing protocol into another its possible to create routing loops.If you dont feel 100% confident about your knowledge on OSPF and EIGRP then I suggest you stop reading now and read more about OSPF / EIGRP or do some labs. One routing protocol can be difficult but when you mix a couple of them the fun really startsHaving said that, lets take a look at a possible redistribution scenario:

Look at the topology picture above. We have routers running EIGRP in AS 1 with the 10.0.0.0 /8 network. OSPF has multiple areas and we have 20.0.0.0 /8 there. At the bottom there are two RIP routers in the 30.0.0.0 /8 network. If we want to have full connectivity in this network well have to do some redistribution.Redistribution is not just for between routing protocols, we have multiple options: Between routing protocols (RIP, OSPF, EIGRP, BGP). Static routes can be redistributed into a routing protocol. Directly connected routes can be redistributed into a routing protocol.Normally you use the network command to advertise directly connected routes into your routing protocol. You can also use the redistribute connected command which will redistribute it into the routing protocol. Lets take a look at some real routers:

In the topology picture above I have three routers. Router Jack is running EIGRP and router James is running RIP. Router John is in the middle and is running EIGRP and RIP. If we want to do redistribution well have to do it on router John. Lets take a look shall we?Jack(config)#router eigrp 12Jack(config-router)#no auto-summaryJack(config-router)#network 192.168.12.0 Jack(config-router)#network 1.1.1.0 0.0.0.255John(config)#router eigrp 12John(config-router)#no auto-summaryJohn(config-router)#network 192.168.12.0John(config-router)#exitJohn(config)#router ripJohn(config-router)#version 2John(config-router)#no auto-summary John(config-router)#network 192.168.23.0James(config)#router ripJames(config-router)#version 2James(config-router)#no auto-summary James(config-router)#network 192.168.23.0 James(config-router)#network 3.3.3.0Here are the router configurations, nothing specialI only advertised the links to get EIGRP and RIP up and running.Jack#show ip route

Gateway of last resort is not set

C 192.168.12.0/24 is directly connected, FastEthernet0/0 1.0.0.0/24 is subnetted, 1 subnetsC 1.1.1.0 is directly connected, Loopback0John#show ip route

Gateway of last resort is not set

C 192.168.12.0/24 is directly connected, FastEthernet0/0 1.0.0.0/24 is subnetted, 1 subnetsD 1.1.1.0 [90/156160] via 192.168.12.1, 00:05:01, FastEthernet0/0R 3.0.0.0/8 [120/1] via 192.168.23.3, 00:00:12, FastEthernet1/0C 192.168.23.0/24 is directly connected, FastEthernet1/0James#show ip route

Gateway of last resort is not set

3.0.0.0/24 is subnetted, 1 subnetsC 3.3.3.0 is directly connected, Loopback0C 192.168.23.0/24 is directly connected, FastEthernet0/0Here are the routing table of all three routers after configuring RIP and EIGRP. You can see router John has learned the loopback interfaces of router James and Jack. Router Jack and James dont have anything in their routing table because router John is not advertising anything. As you can see redistribution is not done automatically.Before I show you the redistribution configurations there are two things you should be aware of: Redistribution happens outbound. If I configure redistribution on router John then nothing will change in the routing table of router John. Router John will redistribute EIGRP routing information into RIP and advertise it to router James. Router John will redistribute RIP routing information into EIGRP and advertise it to router Jack. You need the networks in your local routing table before you can do redistribution. You cant advertise (or redistribute) what you dont haveWhen we redistribute from one routing protocol into another we have to use a seed metric. Each routing protocols uses a different metric: OSPF: Cost EIGRP: K-Values (bandwidth, delay, load and reliability) RIP: Hop countSomehow we have to convert the metric from one routing protocol to another. This is something that doesnt happen automaticallywe have to tell the router what metric to use and its different for each routing protocol.ProtocolDefault Seed Metric

RIPInfinity

EIGRPInfinity

OSPF20 except BGP is 1.

BGPBGP metric is set to IGP metric

This table is important to remember. If you redistribute something into RIP then the default seed metric is infinity. What does RIP do with routes that have an infinite metric? Thats rightthey dont show up in your routing table! This means you have to configure a default hop count for everything you redistribute into RIP or its not going to work.The same thing applies to redistributing into EIGRP. You have to configure the K-values yourself otherwise redistribution is not going to work.OSPF is friendlierif you redistribute into OSPF then the redistributed routes will have a default cost of 20 unless the routing information comes from BGPwhich has a cost of 1.John(config)#router ripJohn(config-router)#default-metric 5John(config)#router eigrp 12John(config-router)#default-metric 1500 100 255 1 1500Heres an example how you can configure the default seed metric by using the default-metric command. Default-metric 5 sets the hop count to 5 for everything we redistribute into RIP.For EIGRP you have to specify the K-values. In my example Im using a bandwidth of 1500, a delay of 100, reliability 255 (which means 100%), load of 1 (1%) and a MTU of 1500. In case you are wondering these are just values that I made up. Everything we redistribute into EIGRP will have this metric.

You are here: Home Cisco CCNP ROUTE IP Routing How to configure Redistribution between OSPF and RIPHow to configure Redistribution between OSPF and RIP Posted on February 21, 2013 by Rene Molenaar in CCNP ROUTE, Cisco, IP Routing In a previous article I explained the basics of Redistribution. Now its time to actually configure some redistribution. In this article well cover redistribution between OSPF and RIP. This is the topology that we will use:

Lets start with the redistribution between OSPF and RIP. First let me show you the router configurations:Jack(config)#router ospf 1Jack(config-router)#network 1.1.1.0 0.0.0.255 area 0Jack(config-router)#network 192.168.12.0 0.0.0.255 area 0John(config)#router ospf 1John(config-router)#network 192.168.12.0 0.0.0.255 area 0John(config)#router ripJohn(config-router)#version 2John(config-router)#no auto-summary John(config-router)#network 192.168.23.0James(config)#router ripJames(config-router)#version 2James(config-router)#network 3.3.3.0James(config-router)#network 192.168.23.0Nothing special here, just OSPF and RIP advertising their networks.Jack#show ip route

Gateway of last resort is not set

C 192.168.12.0/24 is directly connected, FastEthernet0/0 1.0.0.0/24 is subnetted, 1 subnetsC 1.1.1.0 is directly connected, Loopback0John#show ip route

Gateway of last resort is not set

C 192.168.12.0/24 is directly connected, FastEthernet0/0 1.0.0.0/32 is subnetted, 1 subnetsO 1.1.1.1 [110/2] via 192.168.12.1, 00:11:05, FastEthernet0/0 3.0.0.0/24 is subnetted, 1 subnetsR 3.3.3.0 [120/1] via 192.168.23.3, 00:00:20, FastEthernet1/0C 192.168.23.0/24 is directly connected, FastEthernet1/0James#show ip route

Gateway of last resort is not set

3.0.0.0/24 is subnetted, 1 subnetsC 3.3.3.0 is directly connected, Loopback0C 192.168.23.0/24 is directly connected, FastEthernet0/0You can see router John has learned RIP and OSPF information. Time for some redistribution action!John(config)#router ripJohn(config-router)#redistribute ? bgp Border Gateway Protocol (BGP) connected Connected eigrp Enhanced Interior Gateway Routing Protocol (EIGRP) isis ISO IS-IS iso-igrp IGRP for OSI networks metric Metric for redistributed routes mobile Mobile routes odr On Demand stub Routes ospf Open Shortest Path First (OSPF) rip Routing Information Protocol (RIP) route-map Route map reference static Static routes First Im going to redistribute OSPF into RIP. You can see I can choose a lot of different protocols when you use the redistribute command.John(config)#router ripJohn(config-router)#redistribute ospf 1 metric 5This is how I redistribute OSPF (process 1) into RIP. Im setting the hop count to 5. Keep in mind the default seed metric for RIP is infinity. If I dont specify a metric your redistribution will fail!John(config)#router ripJohn(config-router)#default-metric 5I also could have used the default-metric command to set a default hop count for everything Im redistributing.James#show ip route rip R 192.168.12.0/24 [120/5] via 192.168.23.2, 00:00:00, FastEthernet0/0 1.0.0.0/32 is subnetted, 1 subnetsR 1.1.1.1 [120/5] via 192.168.23.2, 00:00:00, FastEthernet0/0This is what the routing table of router James looks like. You can see the OSPF networks that are redistributed into RIP. You can also see the seed metric (hop count) of 5.excellent!John(config)#router ospf 1John(config-router)#redistribute rip subnetsLets redistribute RIP into OSPF now. I can use the redistribute rip subnets command here. The keyword subnets is needed because otherwise OSPF will redistribute classful! I want it to redistribute classless so thats why Ive added the keyword subnets.Jack#show ip route ospf 3.0.0.0/24 is subnetted, 1 subnetsO E2 3.3.3.0 [110/20] via 192.168.12.2, 00:00:21, FastEthernet0/0O E2 192.168.23.0/24 [110/20] via 192.168.12.2, 00:00:21, FastEthernet0/0Lets look at router Jack. You can see OSPF information in the routing table. They show up as external type 2 routes. The cost is 20 (which is the default). OSPF is a bit more sophisticated than RIP and makes a difference between internal and external routes.If routes are redistributed into OSPF as type 2 then every router in the OSPF domain will see the same cost to reach the external networks. If routes are redistributed into OSPF as type 1, then the cost to reach the external networks could vary from router to router.I hope this example helps you to understand redistribution between OSPF and RIP. Make sure you understand the basics before you move on to more complex redistribution scenarios. If you have any questions feel free to ask!

Troubleshooting Metric Redistribution Posted on April 7, 2015 by Rene Molenaar in CCIE R&S, Cisco, IP Routing Redistribution is a difficult topic to master. The configuration is quite easy but if you are not careful you will end up with sub-optimal routing and/or routing loops.When it comes to redistribution issues, there are two possible problems that we can encounter: Metric based Administrative Distance basedIn this lesson well take a look at metric based redistribution problems and how to fix them. To demonstrate this I will use the following topology:

In this topology we have 4 routers. All routers are running RIPv2 while R3 and R4 are also running OSPF on the link between them.

R1 is only used to advertise a network (1.1.1.0 /24) into RIP. This is what the routing configuration looks like right now (without redistribution):R1#show run | section riprouter rip version 2 offset-list 0 out 5 network 1.0.0.0 network 192.168.12.0 no auto-summaryR2#show run | section riprouter rip version 2 network 192.168.12.0 network 192.168.23.0 network 192.168.24.0 no auto-summaryR3#show run | section riprouter rip version 2 network 192.168.23.0 no auto-summaryR4#show run | section riprouter rip version 2 network 192.168.24.0 no auto-summaryEach router runs RIP version 2, nothing special. Heres the OSPF configuration of R3 and R4:R3#show run | section ospfrouter ospf 1 log-adjacency-changes network 192.168.34.0 0.0.0.255 area 0R4#show run | section ospfrouter ospf 1 log-adjacency-changes network 192.168.34.0 0.0.0.255 area 0Lets take a look what the routing tables of R2, R3 and R4 look like now. Lets look at the RIP routes first:R2#show ip route rip 1.0.0.0/24 is subnetted, 1 subnetsR 1.1.1.0 [120/6] via 192.168.12.1, 00:00:09, FastEthernet1/0R3#show ip route ripR 192.168.12.0/24 [120/1] via 192.168.23.2, 00:00:27, FastEthernet0/0 1.0.0.0/24 is subnetted, 1 subnetsR 1.1.1.0 [120/7] via 192.168.23.2, 00:00:27, FastEthernet0/0R 192.168.24.0/24 [120/1] via 192.168.23.2, 00:00:27, FastEthernet0/0R4#show ip route ripR 192.168.12.0/24 [120/1] via 192.168.24.2, 00:00:02, FastEthernet0/0 1.0.0.0/24 is subnetted, 1 subnetsR 1.1.1.0 [120/7] via 192.168.24.2, 00:00:02, FastEthernet0/0R 192.168.23.0/24 [120/1] via 192.168.24.2, 00:00:02, FastEthernet0/0R2 has learned about network 1.1.1.0 /24 from R1 with a hop count of 6. I used an offset-list on R1 to increase the hop count for this topology, Ill show you why in a bit.R3 and R4 also learn about this network and the links in between R1/R2, R2/R3 and R/4. Nothing special so farSince R3 and R4 only run OSPF on the directly connected link they dont have any OSPF routes right now:R3#show ip route ospfR4#show ip route ospfSo far so good. Now we will continue by configuring redistribution. Ill do this step-by-step so you can see what will happen. First we will redistribute RIP into OSPF on R3 and R4:

R3 & R4#(config)#router ospf 1(config-router)#redistribute rip subnetsThe command above redistribute everything from RIP into OSPF. Letsee what R3 and R4 now have in their routing tables:R3#show ip route ospfO E2 192.168.24.0/24 [110/20] via 192.168.34.4, 00:01:02, FastEthernet0/1R3 has now learned through OSPF to reach network 192.168.24.0 /24 with R4 as its next hop. Before we configured redistribution, it had a RIP route for this network with R2 as its next hop. The reason that the RIP route has been removed is because OSPF has a better administrative distance (120 vs 110):

Is this an issue? For this particular topology right now it wont cause any issues. R3 can reach this network through R2 or R4. Lets take a look at R4 now:R4#show ip route ospfO E2 192.168.12.0/24 [110/20] via 192.168.34.3, 00:01:14, FastEthernet0/1 1.0.0.0/24 is subnetted, 1 subnetsO E2 1.1.1.0 [110/20] via 192.168.34.3, 00:01:14, FastEthernet0/1O E2 192.168.23.0/24 [110/20] via 192.168.34.3, 00:01:14, FastEthernet0/1The output of R4 is a bit more interesting. Take a close look at the first two entries: 192.168.12.0 /24 with R3 as its next hop. 1.1.1.0 /24 with R3 as its next hop.R4 used to have RIP routes for these two networks but they have been replaced with these OSPF entries. Is this a problem? It wont cause any issues in this topology but this is what we call sub-optimal routing:

We have connectivity but since R4 prefers OSPF (AD 110) over RIP (AD 120) we will send all traffic destined for 192.168.12.0 /24 and 1.1.1.0 /24 through R3. It works, but its not optimal.Why did R4 learn about these routes through R3 and not the other way around (R3 learning those two networks from R4)? R3 and R4 are both redistributing all RIP routes into OSPF so why is there a difference in the output of their routing tables?It depends on which router has converged first. In my example I started with the redistribution configuration on R3. In this case, R3 will redistribute the RIP routes into OSPF and advertises them to R4. R4 will remove its RIP routes for these networks and installs the OSPF routes.Since R4 doesnt have a RIP route for 192.168.12.0 /24 and 1.1.1.0 /24 in its routing table, they cant be redistributed into OSPF and advertised to R3. If I would have configured R4 first (or reset the OSPF process on R3) then R3 would learn about the redistributed RIP routes through OSPF.We will forget about this sub-optimal routing issue for now, it wont cause any issues for this topology and the goal of this lesson is to explain you the redistribution metric problem. In my second post I will explain how to fix this issue. In case you are curious, the short answer is that you have to set the AD of the OSPF entries for 192.168.12.0 /24 and 1.1.1.0 /24 to a value higher than 120. This causes R3 and R4 to use the RIP routes instead of the OSPF routes.Lets continue by redistributing OSPF into RIP, thats where the real fun starts. Well do this on R3 and R4:R3 & R4#(config)#router ripconfig-router)#redistribute ospf 1 metric 1We redistribute everything from OSPF into RIP. Now take a look what happens with R2:R2#show ip route rip 1.0.0.0/24 is subnetted, 1 subnetsR 1.1.1.0 [120/1] via 192.168.24.4, 00:00:05, FastEthernet0/1R 192.168.34.0/24 [120/1] via 192.168.24.4, 00:00:05, FastEthernet0/1 [120/1] via 192.168.23.3, 00:00:01, FastEthernet0/0Take a good look at the entry for 1.1.1.0 /24. R2 installed this route with R4 as its next hopthis will cause issues, check out this traceroute:R2#traceroute 1.1.1.1

Type escape sequence to abort.Tracing the route to 1.1.1.1

1 192.168.24.4 1388 msec 620 msec 744 msec 2 192.168.34.3 2552 msec 2308 msec 1904 msec 3 192.168.23.2 56 msec 48 msec 48 msec 4 192.168.24.4 76 msec 76 msec 72 msec 5 192.168.34.3 112 msec 124 msec 100 msec 6 192.168.23.2 96 msec 100 msec 92 msec 7 192.168.24.4 124 msec 140 msec 124 msec 8 192.168.34.3 156 msec 168 msec 176 msec 9 192.168.23.2 152 msec 136 msec 156 msec 10 192.168.24.4 176 msec 184 msec 172 msecThats not looking good, we now have a routing loop! Traffic is sent like this:

So why exactly is this happening? This is the metric redistribution issue that this lesson is named after. Lets zoom in on R2:

R2 is receiving a routing update for network 1.1.1.0 /24 on two interfaces. The update from R1 has a hop count of 6 while the update from R3 has a hop count of 1. R2 selects the route with the lowest hop count so it installs the route towards R3.RIP doesnt see the difference between an internal and redistributed route so it just selects the one with the lowest metric. What about other protocols like OSPF or EIGRP? Are they also vulnerable to this metric problem? OSPF doesnt have this issue because it always prefers internal O and O IA routes over O E1 and E2 routes. EIGRP doesnt have this issue because it always prefers internal routes (AD 90) over external routes (AD 170). The only exception to this rule is when the original route is an EIGRP external route. In this case, both routes have an AD of 170.Before we start looking at different solutions to fix this problem, lets pause for a moment, take a deep breath and think about the core issue of the problem that we have here. The problem with the metric that R2 is facing happens because we redistributed the 1.1.1.0 /24 network from RIP into OSPF and then back into RIP:

Advertising a prefix from one routing protocol into another and then back into the first routing protocol is a bad idea. Theres no point feeding this information back into the routing protocol that originated the prefix.You should never redistribute prefixes like this:Routing Protocol X > Y > XThis is a very important redistribution rule, in fact its so important that Ill add it extra large:Redistribution Rule: Never advertise prefixes from routing protocol X into Y and then back into X.If we would prevent R4 (and R3) from redistributing the 1.1.1.0 /24 network back into RIP then R2 would never learn this network with that low hop count and there would be no routing loop.Keep this redistribution rule in mind while we look at the different solutions to fix this problemSolutionsThere are many different methods to solve the metric redistribution issue that you just witnessed. Ill show you the different methods and their (dis)advantages. Its important to know some of the different methods if you are preparing for the CCIE R&S lab. Lets look at the first methodRedistribution FilteringInstead of just redistributing everything from one routing protocol into another, well use some filters to select the prefixes we want to redistribute.We should only redistribute the prefixes that originated in the routing protocol. For example, when we look at OSPF the only network that originated in OSPF is 192.168.34.0 /24 (the link between R3 and R4). This is the only network that we should redistribute into RIP.

Let me show you how to configure a filter when you redistribute:R3 & R4#(config)#ip access-list standard NATIVE_OSPF_ROUTES(config-std-nacl)#permit 192.168.34.0 0.0.0.255

(config)#route-map NATIVE_OSPF permit 10(config-route-map)#match ip address NATIVE_OSPF_ROUTES(config-route-map)#route-map NATIVE_OSPF deny 20

(config)#router rip(config-router)#redistribute ospf 1 metric 1 route-map NATIVE_OSPFFirst we create an access-list that matches the network that we want to redistribute. Secondly we configure a route-map that matches this access-list and finally we attach the route-map to the redistribute command. This fixes our problem since R2 will never learn about network 1.1.1.0 /24 through R3 or R4. Take a look at its routing table:R2#show ip route rip 1.0.0.0/24 is subnetted, 1 subnetsR 1.1.1.0 [120/6] via 192.168.12.1, 00:00:21, FastEthernet1/0Above you can see that R2 now uses the original (and correct) route for network 1.1.1.0 /24. Great! We just solved our first redistribution problem.Instead of using an access-list, you can also use a prefix-list. This might be useful if your CCIE lab has a requirement that tells you not to use access-lists or something. Let me change the route-map:R3 & R4#(config)#ip prefix-list NATIVE_OSPF_ROUTES permit 192.168.34.0/24(config-route-map)#no match ip address NATIVE_OSPF_ROUTES(config-route-map)#match ip address prefix-list NATIVE_OSPF_ROUTESThe end result will be the same.Sometimes it helps to use clear ip route * to speed up convergence. Its also useful to enable debug ip routing to see changes to the routing table on your console.The solution I just showed you meets the dont redistribute routing protocol X > Y > X rule but it has one limitationits not a very scalable solution. When you advertise new prefixes into OSPF, youll have to add them to your access-list or prefix-list.We attached a route-map to the redistribution from OSPF into RIP but we didnt do this for redistribution for RIP into OSPF. Technically it doesnt matter much since OSPF guards itself against this redistribution metric problemit will always prefer internal prefixes over external prefixes. Still, it would be a good idea to prevent prefixes going from OSPF > RIP > OSPF.Lets take a look at another solution which is more scalableRedistribution Route TaggingInstead of manually selecting the prefixes we want to redistribute we can also tag the prefixes. What this means is that whenever we redistribute a prefix, it will be tagged. Heres a illustration:

Above is an example for network 1.1.1.0 /24. When R3 redistributes this network into OSPF, it will add a tag to it. When R4 sees this tag, it wont redistribute it from OSPF to RIP.This way a router will know if the prefix has already been redistributed or not. Let me show you how to do this, first lets get rid of the route-map we used in the previous example:R3 & R4#(config)router rip(config-router)#no redistribute ospf 1 metric 1 route-map NATIVE_OSPF(config-router)#redistribute ospf 1 metric 1I removed the route-map and added the old redistribution command again.This time well create a route-map that tags all prefixes when they are redistributed from RIP into OSPF. Lets do this step-by-step:R3 & R4#(config)#route-map RIP_TO_OSPF permit 10(config-route-map)#set tag 100

(config)#router ospf 1(config-router)#redistribute rip metric 1 subnets route-map RIP_TO_OSPFFirst we create a route-map that permits everything and sets the tag to 100. You can pick whatever value you like. Secondly we apply this route-map to the redistribution of RIP prefixes into OSPF. Now take a look at the OSPF database of R3 and R4:R3#show ip ospf database | begin Type-5 Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag1.1.1.0 192.168.34.4 6 0x80000001 0x0001BB 100192.168.12.0 192.168.34.3 107 0x80000004 0x00EE59 100192.168.23.0 192.168.34.3 107 0x80000004 0x0075C7 100192.168.24.0 192.168.34.4 59 0x80000004 0x0064D6 100R4#show ip ospf database | begin Type-5 Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag192.168.12.0 192.168.34.3 99 0x80000004 0x00EE59 100192.168.23.0 192.168.34.3 99 0x80000004 0x0075C7 100192.168.24.0 192.168.34.4 50 0x80000004 0x0064D6 100You can see that the RIP prefixes have been redistributed into OSPF and are tagged with 100. Our next move is to tell R3 and R4 that when we redistribute from OSPF into RIP that we have to ignore the prefixes that are tagged with 100. Heres how to do it:R3 & R4#(config)#route-map OSPF_TO_RIP deny 10(config-route-map)#match tag 100(config-route-map)#exit(config)#route-map OSPF_TO_RIP permit 20

(config-route-map)#router rip(config-router)#redistribute ospf 1 metric 1 route-map OSPF_TO_RIPWe create a new route-map that denies everything with tag 100 while everything else is permitted. This route-map is attached to the redistribute command under the RIP process. This meets our dont redistribute from routing protocol X > Y back to X rule. Take a look at R2:R2#show ip route rip 1.0.0.0/24 is subnetted, 1 subnetsR 1.1.1.0 [120/6] via 192.168.12.1, 00:00:13, FastEthernet1/0Since R2 never learns about the 1.1.1.0 /24 prefix from OSPF, it will prefer the original route from R1way to go!Now you understand route tagging, let me show you an even better solution. We can create a single route-map that can be used for redistribution in both directions. Heres what it looks like:R3 & R4#(config)#route-map TAGGING deny 10(config-route-map)#match tag 1234(config-route-map)#exit(config)#route-map TAGGING permit 20(config-route-map)#set tag 1234

(config)#router rip(config-router)#redistribute ospf 1 metric 1 route-map TAGGING

(config)#router ospf 1(config-router)#redistribute rip subnets route-map TAGGINGThis route-map wont redistribute a prefix if it has a tag of 1234. If the prefix doesnt have a tag then we will permit it and set the tag to 1234. The route-map has been attached to OSPF and RIP.The logic behind this route-map is that when something has been tagged then it must have been redistributed already and we should ignore it. If there is no tag, we set one and redistribute the prefix. The end result is the same:R2#show ip route rip 1.0.0.0/24 is subnetted, 1 subnetsR 1.1.1.0 [120/6] via 192.168.12.1, 00:00:06, FastEthernet1/0Instead of only looking at the routing table, enabling a debug is also a nice method to see in- and outgoing routing updates:R2#debug ip ripRIP protocol debugging is on

RIP: received v2 update from 192.168.24.4 on FastEthernet0/1 192.168.34.0/24 via 0.0.0.0 in 1 hops

RIP: received v2 update from 192.168.23.3 on FastEthernet0/0 192.168.34.0/24 via 0.0.0.0 in 1 hopsThis tells us that R3 and R4 are only redistributing 192.168.34.0 /24 towards R2.Route tagging is the most convenient method to enforce the redistribution rule of Never advertise prefixes from routing protocol X into Y and then back into X. If you advertise new prefixes in RIP or OSPF then theyll be automatically tagged.We just used a route-map in combination with an access-list, prefix-list and route tagging. These are the most common methods but you can get pretty creative with the match options that a route-map offers. Some of the examples are matching on the next hop IP address or match interface. To get an idea of the possibilities, take a look at this Cisco article.Lets take a look at some other options to solve our metric redistribution problemRedistribution Seed MetricForget about the route-maps for now, lets get back to the original scenario. The problem with R2 accepting the 1.1.1.0 /24 network from R4 (or R3) is that the hop count was an offer it couldnt refuse. Take a look at this picture to refresh your memory:

To make R2 prefer the original information from R1 we could change the seed metric. This is kinda a dirty trick but its a possibility:R3 & R4#(config)#router rip(config-router)#redistribute ospf 1 metric 10By setting the hop count for the redistributed routes into RIP to 10, R2 will prefer the information from R1. This solution doesnt meet our holy redistribution rule and it can be dangerous. When someone increases the hop count on R1 to 11 or higher, well have the same problem again.Still, on a CCIE R&S lab you can expect anything so its good to understand the different possibilities of fixing a problem. Lets take a look at the next solution which is similarOffset-ListIn the previous solution we changed the seed metric. What if R3 and R4 are pre-configured routers and outside of our control? When this is the case, we can use an offset-list on R2 to increase the metric:

Heres what the configuration looks like:R2(config)#ip access-list standard LOOPBACK_R1R2(config-std-nacl)#permit 1.1.1.0 0.0.0.255First we create an access-list that matches the 1.1.1.0 /24 network. Our next move is to attach it to an offset-list:R2(config)#router ripR2(config-router)#offset-list LOOPBACK_R1 in 10 FastEthernet0/1The metric from R1 will now be better than whatever R3 or R4 are offering:R2#show ip route rip 1.0.0.0/24 is subnetted, 1 subnetsR 1.1.1.0 [120/6] via 192.168.12.1, 00:00:13, FastEthernet1/0Just like changing the seed metric, this is a fix that could be used when R3 and R4 are outside of our control. Lets check out another solutionDistribute-list FilteringTo prevent routes from entering the routing table, we can also use a distribute-list. When we get back to the original problem, this is what the routing table of R2 looks like:R2#show ip route rip 1.0.0.0/24 is subnetted, 1 subnetsR 1.1.1.0 [120/1] via 192.168.23.3, 00:00:09, FastEthernet0/0Above you can see that R2 accepted the 1.1.1.0 /24 prefix from R3. We can use distribute-lists to block certain routing updates:

Heres how to configure this:R2(config)#ip access-list standard BLOCK_LOOPBACK_R1R2(config-std-nacl)#deny 1.1.1.0 0.0.0.255R2(config-std-nacl)#permit anyI will use an access-list to filter the prefix but you can use some other options as well:R2(config-router)#distribute-list ? IP access list number IP expanded access list number WORD Access-list name gateway Filtering incoming updates based on gateway prefix Filter prefixes in routing updatesLets attach the access-list to the distribute-list and to the two interfaces pointing to R3 and R4:R2(config-router)#distribute-list BLOCK_LOOPBACK_R1 in FastEthernet 0/0R2(config-router)#distribute-list BLOCK_LOOPBACK_R1 in FastEthernet 0/1R2 will now not accept the information from R3 or R4 and as a result, it will use the information from R1:R2#show ip route rip 1.0.0.0/24 is subnetted, 1 subnetsR 1.1.1.0 [120/6] via 192.168.12.1, 00:00:01, FastEthernet1/0Problem solved! Just like the seed metric and offset-list solutions, this one doesnt meet our redistribution rule. However, changing the metric on R1 wont accept R2s decisions since its not accepting 1.1.1.0 /24 from R3 and R4 at all.I have one more solution for you, the next one is a bit different!Administrative DistanceBack to the original problem, R2 has an incorrect route again from R3:R2#show ip route rip 1.0.0.0/24 is subnetted, 1 subnetsR 1.1.1.0 [120/1] via 192.168.23.3, 00:00:12, FastEthernet0/0We can change the administrative distance for certain prefixes. Lets do this for network 1.1.1.0 /24:R2(config)#ip access-list standard LOOPBACK_R1R2(config-std-nacl)#permit 1.1.1.0 0.0.0.255

R2(config)#router ripR2(config-router)#distance 255 192.168.23.3 0.0.0.0 LOOPBACK_R1R2(config-router)#distance 255 192.168.24.4 0.0.0.0 LOOPBACK_R1When R2 receives RIP information about 1.1.1.0 /24 from R3 or R4 then it will set the administrative distance to 255. Setting it to a value of 121 or higher would do the job but setting it to 255 prevents R2 from installing it in its routing table at all.Heres the end result:R2#show ip route rip 1.0.0.0/24 is subnetted, 1 subnetsR 1.1.1.0 [120/6] via 192.168.12.1, 00:00:13, FastEthernet1/0Problem solved! Instead of changing the administrative distance on R2, we can also do this on R3 or R4. Lets get rid of the configuration we just did on R2:R2(config)#router ripR2(config-router)#no distance 255 192.168.23.3 0.0.0.0 LOOPBACK_R1R2(config-router)#no distance 255 192.168.24.4 0.0.0.0 LOOPBACK_R1Take a look at R3, this is currently the router that is responsible for redistributing 1.1.1.0 /24 into RIP:R3#show ip route ospf 1.0.0.0/24 is subnetted, 1 subnetsO E2 1.1.1.0 [110/1] via 192.168.34.4, 00:36:18, FastEthernet0/1

Lets increase the administrative distance for 1.1.1.0 /24 on R3 and R4:R3 & R4#(config)#ip access-list standard LOOPBACK_R1(config-std-nacl)# permit 1.1.1.0 0.0.0.255

(config)#router ospf 1(config-router)#distance 255 0.0.0.0 255.255.255.255 LOOPBACK_R1R3 and R4 are now unable to install the 1.1.1.0 /24 OSPF route in their routing tables. They are forced to use the RIP information:R3#show ip route | incl 1.1.1.0R 1.1.1.0 [120/7] via 192.168.23.2, 00:00:19, FastEthernet0/0R4#show ip route rip | incl 1.1.1.0R 1.1.1.0 [120/7] via 192.168.24.2, 00:00:26, FastEthernet0/0Above you can see that R3 and R4 are now using the information from RIP. Since they dont have a OSPF entry for this network, they also cant redistribute it into RIP.The solution above is also the solution to get rid of the sub-optimal routing problem. By changing the administrative distance, R3 and R4 are forced to use the original routing information instead of the redistributed routing information.This ensures that R2 wont learn it:R2#show ip route rip 1.0.0.0/24 is subnetted, 1 subnetsR 1.1.1.0 [120/6] via 192.168.12.1, 00:00:12, FastEthernet1/0Problem solved!ConclusionRedistribution is a complex topickeep the redistribution rule in mind that you should never redistribute routing information from routing protocol X into Y and then back into X. When you do face metric-related redistribution issues, you are now able to fix them using a variety of techniques.

VRRP (Virtual Router Redundancy Protocol) Posted on October 6, 2014 by Rene Molenaar in CCNP SWITCH, Cisco, Network Services VRRP (Virtual Router Redundancy Protocol) is very similar to HSRP (Hot Standby Routing Protocol) and can be used to create a virtual gateway. If you dont know why we use virtual gateways then I suggest to read my Introduction to virtual gateways first. Also make sure you check the HSRP lesson first since many of the things I describe there also apply to VRRP.VRRP is very similar to HSRP; if you understood HSRP youll have no trouble with VRRP which is a standard protocol defined by the IETF in RFC 3768. Configuration-wise its pretty much the same but there are a couple of differences.Lets start with an overview:HSRPVRRP

ProtocolCisco proprietaryIETF RFC 3768

Number of groups16 groups maximum255 groups maximum

Active/Standby1 active, 1 standby and multiple candidates.1 active and several backups.

Virtual IP AddressDifferent from real IP addresses on interfacesCan be the same as the real IP address on an interface.

Multicast address224.0.0.2224.0.0.18

TrackingInterfaces or ObjectsObjects

TimersHello timer 3 seconds, hold time 10 seconds.Hello timer 1 second, hold time 3 seconds.

AuthenticationSupportedNot supported in RFC 3768

As you can see there are a number of differences between HSRP and VRRP. Nothing too fancy however. HSRP is a cisco proprietary protocol so you can only use it between Cisco devices.Lets see if we can configure itConfigurationThis is the topology that I will use:SwitchA and SwitchB are multilayer switches and their interfaces are configured as routed ports. We will create a virtual gateway using VRRP on the interfaces facing SwitchC:SwitchA(config)#interface fa0/17SwitchA(config-if)#vrrp 1 ip 192.168.1.3SwitchA(config-if)#vrrp 1 priority 150SwitchA(config-if)#vrrp 1 authentication md5 key-string mykeySwitchB(config-if)#interface fa0/19SwitchB(config-if)#vrrp 1 ip 192.168.1.3SwitchB(config-if)#vrrp 1 authentication md5 key-string mykeyHeres an example how to configure VRRP. You can see the commands are pretty much the same but I didnt type standby but vrrp. I have changed the priority on SwitchA to 150 and Ive enabled MD5 authentication on both switches.SwitchA#%VRRP-6-STATECHANGE: Fa0/17 Grp 1 state Init -> Backup%VRRP-6-STATECHANGE: Fa0/17 Grp 1 state Backup -> MasterSwitchB#%VRRP-6-STATECHANGE: Fa0/19 Grp 1 state Init -> Backup %VRRP-6-STATECHANGE: Fa0/19 Grp 1 state Backup -> Master %VRRP-6-STATECHANGE: Fa0/19 Grp 1 state Master -> BackupYou will see these messages pop-up in your console. VRRP uses different terminology than HSRP. SwitchA has the best priority and will become the master router. SwitchB will become a standby router. Lets see what else we have:SwitchA#show vrrp FastEthernet0/17 - Group 1 State is Master Virtual IP address is 192.168.1.3 Secondary Virtual IP address is 192.168.1.4 Virtual MAC address is 0000.5e00.0101 Advertisement interval is 1.000 sec Preemption enabled Priority is 150 Authentication MD5, key-string "mykey" Master Router is 192.168.1.1 (local), priority is 150 Master Advertisement interval is 1.000 sec Master Down interval is 3.414 secSwitchB#show vrrp FastEthernet0/19 - Group 1 State is Backup Virtual IP address is 192.168.1.3 Virtual MAC address is 0000.5e00.0101 Advertisement interval is 1.000 sec Preemption enabled Priority is 100 Authentication MD5, key-string "mykey" Master Router is 192.168.1.1, priority is 150 Master Advertisement interval is 1.000 sec Master Down interval is 3.609 sec (expires in 3.065 sec)Use show vrrp to verify your configuration. The output looks similar to HSRP; one of the differences is that VRRP uses another virtual MAC address:0000.5e00.01XX (where X = group number)SwitchA(config)#interface fa0/17SwitchA(config-if)#shutdownWe can shut the interface on SwitchA so we can see that SwitchB will take over.SwitchA#%VRRP-6-STATECHANGE: Fa0/17 Grp 1 state Master -> InitSwitchB#%VRRP-6-STATECHANGE: Fa0/19 Grp 1 state Backup -> MasterSame principledifferent terminology!It is possible to configure load balancing for VRRP (or HSRP) but it doesnt work on a per packet schedule or something. Instead, we have to use multiple group numbers. Let me show what Im talking about:SwitchA(config)#interface fa0/17SwitchA(config-if)#vrrp 1 ip 192.168.1.3SwitchA(config-if)#vrrp 1 priority 150SwitchA(config-if)#vrrp 2 ip 192.168.1.4SwitchB(config-if)#interface fa0/19SwitchB(config-if)#vrrp 1 ip 192.168.1.3SwitchB(config-if)#vrrp 2 ip 192.168.1.4SwitchB(config-if)#vrrp 2 priority 150I created two groups so we have two virtual IP addresses: 192.168.1.3 and 192.168.1.4 are both virtual IP addresses we can use as a gateway. SwitchA has the highest priority (150) for virtual IP address 192.168.1.3. SwitchB has the highest priority (150) for virtual IP address 192.168.1.4.You can now use 192.168.1.3 and 192.168.1.4 as default gateways for your computers and SwitchA and SwitchB will share the load. You can use this like I did to have load balancing within a VLAN or you can do this on a per VLAN basis.This is all I have on VRRP for now. I hope you enjoyed this lesson!