Any Transport Over MPLS

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
HDLC
I 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.
Configuration
First we will enable OSPF to advertise the loopback interfaces, these will be used as the router
ID for MPLS LDP:
PE1(config)#router ospf 1
PE1(config-router)#network 192.168.12.0 0.0.0.255 area 0
P(config)#router ospf 1
P(config-router)#network 192.168.12.0 0.0.0.255 area 0
PE2(config)#router ospf 1
Now we will enable MPLS LDP on the interfaces connecting the PE1, P and PE2 routers:
PE1(config)#interface fastEthernet 0/1
PE1(config-if)#mpls ip
P(config)#interface fastEthernet 0/0
P(config-if)#mpls ip
P(config)#interface fastEthernet 0/1
P(config-if)#mpls ip
PE2(config)#interface fastEthernet 0/0
PE2(config-if)#mpls ip
Just 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
That 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
PE1(config-if)#xconnect 3.3.3.3 13
PE2(config)#interface fastEthernet
PE2(config-if)#xconnect 1.1.1.1 13
0/0
encapsulation mpls
0/1
encapsulation mpls
We need to use the xconnect command between PE1 and PE2. The VC ID (13) has to be the
same on both routers.
Verification
First we will check our LDP peers:
PE1#show mpls ldp neighbor 3.3.3.3
TCP connection: 3.3.3.3.64567 - 1.1.1.1.646
State: Oper; Msgs sent/rcvd: 15/15; Downstream
Up time: 00:05:19
LDP 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

TCP connection: 1.1.1.1.646 - 3.3.3.3.64567
Up time: 00:05:38
Targeted Hello 3.3.3.3 -> 1.1.1.1, active, passive
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:
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:
MTU: 1500,
Interface Desc: n/a
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:
MTU: 1500,
Interface Desc: n/a
CV Type: LSPV [2]
Remote Label: 19
Cbit: 1,
VC Type: Ethernet,
GroupID:
MTU: 1500,
Interface Desc: n/a
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
UP
PE2#show mpls l2transport vc
Local intf
---------------------Fa0/1
Local circuit
Dest address
VC ID
Status
-------------------------- --------------- ---------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 ms
Our 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 AS
BGP Prevent Transit AS

By 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 Filtering
Prefix-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 1
R1(config-router)#neighbor 192.168.12.2 remote-as 2
ISP1(config)#router bgp 2
ISP1(config-router)#neighbor 192.168.12.1 remote-as 1
ISP2(config-router)#neighbor 192.168.13.1 remote-as 1
The 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)#network 1.1.1.0 mask 255.255.255.0
ISP1(config-router)#network 2.2.2.0 mask 255.255.255.0
ISP2(config-router)#network 3.3.3.0 mask 255.255.255.0
With 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.11
Status codes: s suppressed, d damped, h history, * valid, > best, i internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
*> 1.1.1.0/24
*> 2.2.2.0/24
*> 3.3.3.0/24
ISP2#show ip bgp
Next Hop
192.168.12.1
0.0.0.0
192.168.12.1
Metric LocPrf Weight Path

0
0 1 i
0
32768 i
0 1 3 i

Network
*> 1.1.1.0/24
*> 2.2.2.0/24
*> 3.3.3.0/24
Next Hop
192.168.13.1
192.168.13.1
0.0.0.0

0
0 1 i
0 1 2 i
0
32768 i
The 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-list

Using 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 out
R1(config-router)#neighbor 192.168.13.3 filter-list 1 out
The ^$ 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
Network
*> 1.1.1.0/24
*> 2.2.2.0/24
*> 3.3.3.0/24
Next Hop
0.0.0.0
192.168.12.2
192.168.13.3

0
32768 i
0
0 2 i
0
0 3 i
R1 still knows about the prefixes from the ISP routers. What about ISP1 and ISP2?
ISP1#show ip bgp
Network
*> 1.1.1.0/24
Next Hop
192.168.12.1

0
0 1 i
*> 2.2.2.0/24
0.0.0.0
0
32768 i
ISP2#show ip bgp
Network
*> 1.1.1.0/24
*> 3.3.3.0/24
Next Hop
192.168.13.1
0.0.0.0

0
0 1 i
0
32768 i
ISP1 and ISP2 only know about the 1.1.1.0 /24 network. Excellent, we are no longer a transit
AS! On to the next method
No-Export Community
Using 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-EXPORT
R1(config-route-map)#set community no-export
R1(config-router)#neighbor 192.168.12.2 route-map NO-EXPORT in
R1(config-router)#neighbor 192.168.13.3 route-map NO-EXPORT in
Im 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 <ip> sendcommunity command.
Lets see what ISP1 and ISP2 think about our configuration:
ISP1#show ip bgp
Network
Next Hop
*> 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
ISP2#show ip bgp
Network
*> 1.1.1.0/24
*> 3.3.3.0/24
Next Hop
192.168.13.1
0.0.0.0

0
0 1 i
0
32768 i
They only know about network 1.1.1.0 /24. Onto the next method!
Prefix-List Filtering
Using 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 out
The prefix-list above will only advertise 1.1.1.0 /24 to the ISP routers. Lets verify the
configuration:
ISP1#show ip bgp
Network
Next Hop
*> 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
ISP2#show ip bgp
Network
*> 1.1.1.0/24
*> 3.3.3.0/24
Next Hop
192.168.13.1
0.0.0.0

0
0 1 i
0
32768 i
The prefix-list is working as it should, onto the last exercise!
This method is similar to using the prefix-list but this time well use an access-list.
R1(config)#ip access-list standard NO-TRANSIT
R1(config-std-nacl)#permit 1.1.1.0 0.0.0.255
R1(config-router)#neighbor 192.168.12.2 distribute-list NO-TRANSIT out
R1(config-router)#neighbor 192.168.13.3 distribute-list NO-TRANSIT out
Time to check the ISPs:

ISP1#show ip bgp

Network
Next Hop
*> 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
ISP2#show ip bgp
Network
*> 1.1.1.0/24
*> 3.3.3.0/24
Next Hop
192.168.13.1
0.0.0.0

0
0 1 i
0
32768 i
Thats 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 Example

In 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 1
R1(config-router)#network
192.168.12.1 0.0.0.0 area 0

1.1.1.1 0.0.0.0 area 0
192.168.12.2 0.0.0.0 area 0
192.168.23.2 0.0.0.0 area 0
192.168.23.3 0.0.0.0 area 0
3.3.3.3 0.0.0.0 area 0
Make 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/0
R1(config-if)#mpls ip
Enabling MPLS is simple enough, lets verify that we have neighbors:

R2#show mpls ldp neighbor
TCP connection: 1.1.1.1.646 - 192.168.23.2.35345
Up time: 00:00:21
FastEthernet0/0, Src IP addr: 192.168.12.1
192.168.12.1
1.1.1.1
TCP connection: 3.3.3.3.646 - 192.168.23.2.45741
Up time: 00:00:03
FastEthernet1/0, Src IP addr: 192.168.23.3
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
tag
tag or VC
or Tunnel Id
16
17
3.3.3.3/32
17
Pop tag
192.168.23.0/24
Local Outgoing
Prefix
tag
tag or VC
or Tunnel Id
Bytes tag
switched
0
0
Outgoing
interface
Fa0/0
Fa0/0
Next Hop
Bytes tag
switched
Outgoing
interface
Next Hop
192.168.12.2
192.168.12.2
16
Pop tag
1.1.1.1/32
17
Pop tag
3.3.3.3/32
Local Outgoing
Prefix
tag
tag or VC
or Tunnel Id
16
Pop tag
192.168.12.0/24
17
16
1.1.1.1/32
0
0
Fa0/0
Fa1/0
192.168.12.1
192.168.23.3
Bytes tag
switched
0
0
Outgoing
interface
Fa0/0
Fa0/0
Next Hop
192.168.23.2
192.168.23.2
With MPLS running and labels being advertised, we can continue and create the two VRFs:
R1(config)#ip vrf BLUE
R1(config-vrf)#rd 100:1
R1(config-vrf)#route-target export 100:1
R1(config-vrf)#route-target import 100:3
VRF 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 loopback1
R1(config-if)#ip vrf forwarding BLUE
R1(config-if)#ip address 11.11.11.11 255.255.255.0
Loopback 1 has an IP address and is added to VRF blue. Now lets do the same thing on R3:
R3(config)#ip vrf RED
R3(config-vrf)#rd 100:3
R3(config-vrf)#route-target export 100:3
R3(config-vrf)#route-target import 100:1
R3(config)#interface loopback 1
R3(config-if)#ip vrf forwarding RED
R3(config-if)#ip address 33.33.33.33 255.255.255.0
On R3 well create VRF red and use 100:3 as the RD. Now we can configure BGP on both
routers:
R1(config-router)#neighbor 3.3.3.3 update-source loopback 0
R1(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)#exit
R1(config-router)#address-family ipv4 unicast vrf BLUE
R1(config-router-af)#redistribute connected
R3(config-router)#neighbor 1.1.1.1 update-source loopback 0
R3(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)#exit
R3(config-router)#address-family ipv4 unicast vrf RED
R3(config-router-af)#redistribute connected
Above 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 13
BGP table version is 3, main routing table version 3
2 network entries using 274 bytes of memory
2 path entries using 136 bytes of memory
2/1 BGP path/bestpath attribute entries using 248 bytes of memory
1 BGP extended community entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 682 total bytes of memory
BGP activity 2/0 prefixes, 2/0 paths, scan interval 15 secs
Neighbor V
AS MsgRcvd MsgSent
TblVer InQ OutQ Up/Down State/PfxRcd
3.3.3.3
4
13
7
5
3
0
0 00:02:29
1
R3#show bgp vpnv4 unicast all summary
BGP router identifier 3.3.3.3, local AS number 13
BGP table version is 5, main routing table version 5
3 network entries using 411 bytes of memory
3 path entries using 204 bytes of memory
3/2 BGP path/bestpath attribute entries using 372 bytes of memory
2 BGP extended community entries using 48 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 1035 total bytes of memory
BGP activity 7/4 prefixes, 7/4 paths, scan interval 15 secs
Neighbor
1.1.1.1
V
4
AS MsgRcvd MsgSent
13
25
26
TblVer
5
InQ OutQ Up/Down State/PfxRcd

0
0 00:04:44
1
R1 and R3 have received a prefix from each other, lets find out what they got:
R1#show bgp vpnv4 unicast all
Network
Next Hop
Route Distinguisher: 100:1 (default for
*> 11.11.11.0/24
0.0.0.0
*>i33.33.33.0/24
3.3.3.3
Route Distinguisher: 100:3
*>i33.33.33.0/24
3.3.3.3
R3#show bgp vpnv4 unicast all
BGP table version is 5, local router ID
Status codes: s suppressed, d damped, h
internal,

vrf BLUE)
0
32768 ?
0
100
0 ?
0
100
0 ?
is 3.3.3.3
history, * valid, > best, i -
Network
Next Hop
Route 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
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 ms
There 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 0
Well do this the easy way and activate OSPF on all interfaces. Now lets enable MPLS on the
FastEthernet interfaces:
R1(config)#interface fastEthernet
R2(config-if)#exit
0/0
0/0
0/1
0/0
Lets check if we have LDP neighbors:

R2#show mpls ldp neighbor | include Peer
So far so good, now lets take a look at the LDP labels that have been generated:
Local Outgoing
Prefix
tag
tag or VC
or Tunnel Id
16
Pop tag
2.2.2.2/32
17
17
33.33.33.33/32
18
18
3.3.3.3/32
19
Pop tag
22.22.22.22/32
20
Pop tag
192.168.23.0/24
Local Outgoing
Prefix
Bytes tag
switched
0
0
0
0
0
Outgoing
interface
Fa0/0
Fa0/0
Fa0/0
Fa0/0
Fa0/0
Next Hop
Bytes tag
Outgoing
Next Hop
192.168.12.2
192.168.12.2
192.168.12.2
192.168.12.2
192.168.12.2
tag
tag or VC
or Tunnel Id
16
Pop tag
1.1.1.1/32
17
Pop tag
33.33.33.33/32
18
Pop tag
3.3.3.3/32
19
Pop tag
11.11.11.11/32
Local Outgoing
Prefix
tag
tag or VC
or Tunnel Id
16
Pop tag
192.168.12.0/24
17
16
1.1.1.1/32
18
Pop tag
2.2.2.2/32
19
Pop tag
22.22.22.22/32
20
19
11.11.11.11/32
switched
0
0
0
0
interface
Fa0/0
Fa0/1
Fa0/1
Fa0/0
Bytes tag
switched
0
0
0
0
0
Outgoing
interface
Fa0/0
Fa0/0
Fa0/0
Fa0/0
Fa0/0
192.168.12.1
192.168.23.3
192.168.23.3
192.168.12.1
Next Hop
192.168.23.2
192.168.23.2
192.168.23.2
192.168.23.2
192.168.23.2
For 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.0
R1(config)#no mpls ldp advertise-labels
R1(config)#mpls ldp advertise-labels for 1
First 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 network
Lets verify our work:
Local Outgoing
Prefix
tag
tag or VC
or Tunnel Id
16
Pop tag
2.2.2.2/32
17
Untagged
33.33.33.33/32
18
Untagged
3.3.3.3/32
19
Untagged
22.22.22.22/32
20
Untagged
192.168.23.0/24
Local Outgoing
Prefix
tag
tag or VC
or Tunnel Id
16
Pop tag
1.1.1.1/32
17
Untagged
33.33.33.33/32
18
Pop tag
3.3.3.3/32
19
Untagged
11.11.11.11/32
Local Outgoing
Prefix
tag
tag or VC
or Tunnel Id
16
Untagged
192.168.12.0/24
17
Untagged
1.1.1.1/32
18
Pop tag
2.2.2.2/32
19
Untagged
22.22.22.22/32
Bytes tag
switched
0
0
0
0
0
Outgoing
interface
Fa0/0
Fa0/0
Fa0/0
Fa0/0
Fa0/0
Next Hop
Bytes tag
switched
0
0
0
0
Outgoing
interface
Fa0/0
Fa0/1
Fa0/1
Fa0/0
Next Hop
Bytes tag
switched
0
0
0
0
Outgoing
interface
Fa0/0
Fa0/0
Fa0/0
Fa0/0
Next Hop
192.168.12.2
192.168.12.2
192.168.12.2
192.168.12.2
192.168.12.2
192.168.12.1
192.168.23.3
192.168.23.3
192.168.12.1
192.168.23.2
192.168.23.2
192.168.23.2
192.168.23.2
20
Untagged
11.11.11.11/32
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 starts
Having 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 12
Jack(config-router)#no auto-summary
Jack(config-router)#network 192.168.12.0
Jack(config-router)#network 1.1.1.0 0.0.0.255
John(config)#router eigrp 12
John(config-router)#no auto-summary
John(config-router)#network 192.168.12.0
John(config-router)#exit
John(config)#router rip
John(config-router)#version 2
James(config)#router rip
James(config-router)#version 2
James(config-router)#no auto-summary
James(config-router)#network 192.168.23.0
Here 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 subnets
C
1.1.1.0 is directly connected, Loopback0
John#show ip route

C

D
1.1.1.0 [90/156160] via 192.168.12.1, 00:05:01, FastEthernet0/0
R
3.0.0.0/8 [120/1] via 192.168.23.3, 00:00:12, FastEthernet1/0
C
James#show ip route
C
C
Here 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.
o Router John will redistribute EIGRP routing information into RIP and
advertise it to router James.
o Router John will redistribute RIP routing information into EIGRP and
advertise it to router Jack.
o You need the networks in your local routing table before you can do
redistribution. You cant advertise (or redistribute) what you dont have
When 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 count
Somehow 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.
Protocol
RIP
EIGRP
Default Seed Metric

Infinity
Infinity
OSPF
BGP
20 except BGP is 1.
BGP 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)#default-metric 5
John(config)#router eigrp 12
John(config-router)#default-metric 1500 100 255 1 1500
Heres 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 RIP
How 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 1
Jack(config-router)#network 1.1.1.0 0.0.0.255 area 0
Jack(config-router)#network 192.168.12.0 0.0.0.255 area 0
John(config)#router ospf 1
John(config-router)#network 192.168.12.0 0.0.0.255 area 0
John(config-router)#version 2
James(config)#router rip
James(config-router)#version 2
Nothing special here, just OSPF and RIP advertising their networks.
Jack#show ip route
C

C
John#show ip route
C

O
R
C
James#show ip route
C
C

You can see router John has learned RIP and OSPF information. Time for some redistribution
action!
John(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
<cr>
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)#redistribute ospf 1 metric 5
This 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)#default-metric 5
I also could have used the default-metric command to set a default hop count for everything
Im redistributing.
James#show ip route rip
R
R
This 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 1
John(config-router)#redistribute rip subnets
Lets 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
O E2
O E2 192.168.23.0/24 [110/20] via 192.168.12.2, 00:00:21, FastEthernet0/0
Lets 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 based
In 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
router rip
version 2
offset-list 0 out 5
network 1.0.0.0
network 192.168.12.0
no auto-summary
router rip
version 2
network 192.168.12.0
network 192.168.23.0
network 192.168.24.0
no auto-summary
router rip
version 2
network 192.168.23.0
no auto-summary
router rip
version 2
network 192.168.24.0
no auto-summary
rip
rip
rip
rip
Each router runs RIP version 2, nothing special. Heres the OSPF configuration of R3 and R4:
R3#show run | section ospf
router ospf 1
log-adjacency-changes
network 192.168.34.0 0.0.0.255 area 0
R4#show run | section ospf
router ospf 1
log-adjacency-changes
network 192.168.34.0 0.0.0.255 area 0
Lets 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
R
R
R
R
R
R
R
R2 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 far
Since R3 and R4 only run OSPF on the directly connected link they dont have any OSPF
routes right now:
R3#show ip route ospf
So 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)#redistribute rip subnets
The command above redistribute everything from RIP into OSPF. Letsee what R3 and R4
now have in their routing tables:
R3 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:
O E2
The 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 rip
config-router)#redistribute ospf 1 metric 1
We redistribute everything from OSPF into RIP. Now take a look what happens with R2:
R
R
[120/1] via 192.168.23.3, 00:00:01, FastEthernet0/0
Take a good look at the entry for 1.1.1.0 /24. R2 installed this route with R4 as its next hop
this will cause issues, check out this traceroute:
R2#traceroute 1.1.1.1
Tracing the route to 1.1.1.1
1
2
3
4
5
6
7
8
9
10
192.168.24.4
192.168.34.3
192.168.23.2
192.168.24.4
192.168.34.3
192.168.23.2
192.168.24.4
192.168.34.3
192.168.23.2
192.168.24.4
1388 msec 620 msec 744 msec

Thats 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 > X
This 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
problem
Solutions
There 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 method
Redistribution Filtering
Instead 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_OSPF
First 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:

R
Above 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_ROUTES
The 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 scalable

Redistribution Route Tagging
Instead 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 1
I 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)#redistribute rip metric 1 subnets route-map RIP_TO_OSPF
First 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
1.1.1.0
192.168.12.0
192.168.23.0
192.168.24.0
R4#show ip ospf
ADV Router
Age
Seq#
192.168.34.4
6
0x80000001
192.168.34.3
107
0x80000004
192.168.34.3
107
0x80000004
192.168.34.4
59
0x80000004
database | begin Type-5
Type-5 AS External Link States
Checksum
0x0001BB
0x00EE59
0x0075C7
0x0064D6
Tag
100
100
100
100
Link ID
192.168.12.0
192.168.23.0
192.168.24.0
ADV Router
192.168.34.3
192.168.34.3
192.168.34.4
Age
99
99
50
Seq#
0x80000004
0x80000004
0x80000004
Checksum
0x00EE59
0x0075C7
0x0064D6
Tag
100
100
100
You 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_RIP
We 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:
R
Since 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)#redistribute rip subnets route-map TAGGING
This 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:
Instead of only looking at the routing table, enabling a debug is also a nice method to see inand outgoing routing updates:
R2#debug ip rip
RIP 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 hops
This 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 problem
Redistribution Seed Metric
Forget 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 10
By 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 similar
Offset-List
In 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_R1
First 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 rip
R2(config-router)#offset-list LOOPBACK_R1 in 10 FastEthernet0/1
The metric from R1 will now be better than whatever R3 or R4 are offering:

R
Just 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 solution
To 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:
R
Above 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_R1
R2(config-std-nacl)#deny 1.1.1.0 0.0.0.255
R2(config-std-nacl)#permit any
I will use an access-list to filter the prefix but you can use some other options as well:
R2(config-router)#distribute-list ?
<1-199>
IP access list number
<1300-2699> IP expanded access list number
WORD
Access-list name
gateway
Filtering incoming updates based on gateway
prefix
Filter prefixes in routing updates
Lets 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/0

R2(config-router)#distribute-list BLOCK_LOOPBACK_R1 in FastEthernet 0/1
R2 will now not accept the information from R3 or R4 and as a result, it will use the
information from R1:
R
Problem 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 Distance
Back to the original problem, R2 has an incorrect route again from R3:
R
We 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_R1
R2(config-router)#distance 255 192.168.23.3 0.0.0.0 LOOPBACK_R1
R2(config-router)#distance 255 192.168.24.4 0.0.0.0 LOOPBACK_R1
When 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:
R
Problem 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)#no distance 255 192.168.23.3 0.0.0.0 LOOPBACK_R1
R2(config-router)#no distance 255 192.168.24.4 0.0.0.0 LOOPBACK_R1
Take a look at R3, this is currently the router that is responsible for redistributing 1.1.1.0 /24
into RIP:
O E2
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)#distance 255 0.0.0.0 255.255.255.255 LOOPBACK_R1
R3 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
R
R4#show
R
ip route | incl 1.1.1.0

ip route rip | incl 1.1.1.0
Above 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:

R
Problem solved!
Conclusion
Redistribution 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:
Protocol
HSRP
VRRP
Cisco proprietary
IETF RFC 3768
Number of groups 16 groups maximum
255 groups maximum
Active/Standby
1 active, 1 standby and

multiple candidates.
Virtual IP Address
Different from real IP addresses Can be the same as the real IP

on interfaces
address on an interface.
1 active and several backups.
Multicast address 224.0.0.2
224.0.0.18
Tracking
Interfaces or Objects
Objects
Timers
Hello timer 3 seconds, hold

time 10 seconds.
Hello timer 1 second, hold time

3 seconds.
Authentication
Supported
Not 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 it
Configuration
This 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/17
SwitchA(config-if)#vrrp 1 ip 192.168.1.3
SwitchA(config-if)#vrrp 1 priority 150
SwitchA(config-if)#vrrp 1 authentication md5 key-string mykey
SwitchB(config-if)#interface fa0/19
SwitchB(config-if)#vrrp 1 ip 192.168.1.3
SwitchB(config-if)#vrrp 1 authentication md5 key-string mykey
Heres 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:
SwitchB#
Fa0/17 Grp 1 state Backup -> Master

Fa0/19 Grp 1 state Init -> Backup
Fa0/19 Grp 1 state Backup -> Master
Fa0/19 Grp 1 state Master -> Backup
You 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 sec
SwitchB#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-if)#shutdown
We 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 -> Init
SwitchB#
%VRRP-6-STATECHANGE: Fa0/19 Grp 1 state Backup -> Master
Same 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-if)#vrrp 1 priority 150

SwitchB(config-if)#interface fa0/19
SwitchB(config-if)#vrrp 2 priority 150
I 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!

Any Transport Over MPLS

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Any Transport Over MPLS

Caricato da

Copyright:

Formati disponibili

Any Transport Over MPLS (AToM)

ATM Cell Relay

Just to be sure lets verify that we have LDP neighbors:

PE2#show mpls ldp neighbor 1.1.1.1

Type escape sequence to abort.

BGP Prevent Transit AS

Filter-list with AS PATH access-list.

Metric LocPrf Weight Path

BGP table version is 4, local router ID is 33.33.33.33

Metric LocPrf Weight Path

Filter-list with AS PATH access-list

Metric LocPrf Weight Path

Metric LocPrf Weight Path

Metric LocPrf Weight Path

Metric LocPrf Weight Path

Metric LocPrf Weight Path

The prefix-list is working as it should, onto the last exercise!

Time to check the ISPs:

Origin codes: i - IGP, e - EGP, ? - incomplete

Metric LocPrf Weight Path

MPLS VPN Configuration Example

192.168.12.1 0.0.0.0 area 0

Enabling MPLS is simple enough, lets verify that we have neighbors:

Above we configured a couple of things for BGP:

Lets verify our configuration:

InQ OutQ Up/Down State/PfxRcd

Metric LocPrf Weight Path

MPLS LDP Label Filtering Example

Posted on May 7, 2013

in CCIE R&S, Cisco, MPLS

Lets check if we have LDP neighbors:

Posted on February 21, 2013

in CCNP ROUTE, Cisco, IP Routing

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.

192.168.12.0/24 is directly connected, FastEthernet0/0

Gateway of last resort is not set

192.168.12.0/24 is directly connected, FastEthernet0/0

Redistribution happens outbound. If I configure redistribution on router John then

EIGRP: K-Values (bandwidth, delay, load and reliability)

RIP: Hop count

Default Seed Metric

How to configure Redistribution between

Posted on February 21, 2013

in CCNP ROUTE, Cisco, IP Routing

192.168.12.0/24 is directly connected, FastEthernet0/0

192.168.12.0/24 is directly connected, FastEthernet0/0

3.0.0.0/24 is subnetted, 1 subnets

Troubleshooting Metric Redistribution

Posted on April 7, 2015

in CCIE R&S, Cisco, IP Routing

Administrative Distance based

192.168.12.0 /24 with R3 as its next hop.

1.1.1.0 /24 with R3 as its next hop.

1388 msec 620 msec 744 msec

Let me show you how to configure a filter when you redistribute:

R2#show ip route rip

The end result will be the same.

Lets take a look at another solution which is more scalable

1.1.1.0 [120/6] via 192.168.12.1, 00:00:06, FastEthernet1/0

Heres what the configuration looks like:

R2#show ip route rip

Heres how to configure this: