Deploying Cisco traffic generator in GNS3


Goal: Deploy TRex, a realistic Cisco traffic generator, to test devices in GNS3.

TRex traffic generator is a tool designed to benchmark platforms using realistic traffic.
One of the tools through which TRex can be learned and tested is a virtual machine instance, fully simulating TRex without the need for any additional hardware.

The TRex Virtual Machine is based on Oracle’s Virtual Box freeware.
It is designed to enable TRex newbies to explore this tool without any special resources.

Download the virtual appliance ova file: http://trex-tgn.cisco.com/trex/T_Rex_162_VM_Fedora_21.ova

Open the image in VMWare (I am using VMWare workstation)

From GNS3 import the VMWare device:

Edit the VM template and make sure to select “Allow GNS3 to use any configured VMware adapter”

Selection_140

Insert the a device to test, DUT (Device Under Test), in our case it is a Cisco IOU router and build the following topology, in which TRex will play the role of the client and the server for the generated traffic.

Topology

Selection_132

Because TRex doesn’t implement ARP, we have to manually indicate the router MAC addresses of the directly connected interfaces.
You can set TRex to match the DUT MACs or DUT to match the default MAC configured on TRex. We opt for the first solution:

Note the router interface MAC addresses:

Selection_141

Login to TRex through the console:

  • Username: trex
  • Password: trex

and edit Trex configuration file

/etc/trex_cfg.yaml

and change the DUT MACs

Screenshot - 260716 - 23:33:48

Make sure the list of interfaces ids match the ones defined by dpdk_nic_bind.py

cd v1.62

sudo ./dpdk_nic_bind.py –status

Selection_125

We also need to set our router under test with the MAC addersses used by TRex for the traffic.

On the IOU router:

IOU1(config-if)#int e0/0
IOU1(config-if)#ip address 192.168.10.2 255.255.255.0
IOU1(config-if)#du fu
IOU1(config-if)#no sh
IOU1(config-if)#int e0/1
IOU1(config-if)#ip address 192.168.20.2 255.255.255.0
IOU1(config-if)#du fu
IOU1(config-if)#no sh

IOU1(config)#arp 192.168.10.1  0800.2723.21dc ARPA
IOU1(config)#arp 192.168.20.1  0800.2723.21dd ARPA
IOU1(config)#do sh arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  192.168.10.1            –   0800.2723.21dc  ARPA
Internet  192.168.20.1            –   0800.2723.21dd  ARPA
IOU1(config)#

e0/1 and e0/2 IP addresses are configured with 192.168.10.2 and 192.168.20.2. In fact it doesn’t matter for TRex because we have routes to forward traffic out the appropriate interfaces to reach TRex interfaces.

On the router set routes to the emulated client and servers:

ip route 16.0.0.0 255.0.0.0 192.168.10.1
ip route 48.0.0.0 255.0.0.0 192.168.20.1

For this lab we will generate IMIX traffic (64byte UDP packets profile) from emulated clients and servers using virtual IP range configurable in 16.0.0.[1-255] and 48.0.[0.1-255.255]

Back to TRex:

cap2/imix_64.yaml

Selection_154

So let’s configure our router to route traffic destined to previous ranges out the appropriate interfaces.

IOU router:

IOU1(config)#ip route 16.0.0.0 255.0.0.0 192.168.10.1
IOU1(config)#ip route 48.0.0.0 255.0.0.0 192.168.20.1

Start the emulation on Trex:

sudo ./t-rex-64 -f cap2/imix_64.yaml  -d 60 -m 40000  -c 1

Selection_152

You can observe the generated traffic passing through the router with Wireshark

Selection_153

For more inf. please refer to

https://trex-tgn.cisco.com/trex/doc/trex_manual.html#_dns_basic_example

References:

Advertisements

Embedded Packet Capture, let’s go fishing for some packets!


EPC (Embedded Packet Capture) is another useful troubleshooting tool to occasionally capture traffic to be analyzed locally or exported to remote device. Occasionally, in contrast with RITE (Router IP Traffic Export) or SPAN on switches which are meant to have permanent flow of copied traffic directed to a traffic analyzer or IDS (Intrusion Detection System).

The configuration workflow is straightforward, but I would like to make a conceptual graphical analogy to illustrate it.

Let’s imagine traffic flowing through a router interface like the following:

Embedded Packet Capture

1- Capture point:


Specify the protocol to capture, the interface and the direction, this is the Here you indicate which IP protocol you need to capture.

monitor capture point ip cef CAPTURE_POINT fastEthernet 0/0 both
monitor capture point ipv6 cef CAPTURE_POINT fastEthernet 0/0 both

2- Packet buffer:


Memory area where the frames are stored once captured. 

monitor capture buffer CAPTURE_BUFFER

 

Embedded Packet Capture

3- ACL:


If needed you can filter a specific type of traffic, available only for IPv4. 

(config)#access-list 100 permit icmp host 192.168.0.1 host 172.16.1.1#monitor capture buffer CAPTURE_BUFFER filter access-list 100 

 

Except the optional IPv4 ACL, configured at the global configuration mode, everything else is configured at the privileged EXEC mode.

Embedded Packet Capture

4- Associate capture point with capture buffer

monitor capture point associate CAPTURE_POINT CAPTURE_BUFFER

You can associate multiple capture points (on the same or multiple interfaces) to the same buffer.

Embedded Packet Capture

5- Start and stop capture process

monitor capture point start CAPTURE_POINTmonitor capture point stop CAPTURE_POINT

 concept6

If you are familiar with wireshark, it will be easier to remember the steps needed to capture traffic.

Wireshark analogy

wireshark and Embedded Packet Capture

Deployment 1

Two capture points are created to capture IPv4 and IPv6 traffic into separate capture buffers. 

monitor capture point ipv6 cef CAPTURE_POINT6 fa0/0 bothmonitor capture buffer CAPTURE_BUFFER6monitor capture point associate CAPTURE_POINT6 CAPTURE_BUFFER6

!

monitor capture point ip cef CAPTURE_POINT4 fa0/0 both

monitor capture buffer CAPTURE_BUFFER4

monitor capture point associate CAPTURE_POINT4 CAPTURE_BUFFER4

Following is the result on the router

Deployment 2

Two capture points are created to capture IPv4 and IPv6 traffic into single capture buffer. 

monitor capture point ipv6 cef CAPTURE_POINT6 fa0/0 bothmonitor capture point ip cef CAPTURE_POINT4 fa0/0 both!monitor capture buffer CAPTURE_BUFFER46

!

monitor capture point associate CAPTURE_POINT6 CAPTURE_BUFFER46

monitor capture point associate CAPTURE_POINT4 CAPTURE_BUFFER46

 

Following is the result on the router

Exporting

!Example of export to tftpR1#monitor capture buffer CAPTURE_BUFFER46 export ftp://login:password@192.168.0.32/Volume_1/ecp.pcapWriting Volume_1/ecp.pcap

R1#

!Example of export to tftp

R1# monitor capture buffer CAPTURE_BUFFER46 export tftp://192.168.0.145/ecp.pcap

!

R1#

And the file opened in wireshark:

EPC traffic opened with wireshark

wireshark

That’s all folks!

IPv6 multicast over IPv6 IPSec VTI


IPv4 IPSec doesn’t support multicast, we need to use GRE (unicast) to encapsulate multicast traffic and encrypt it. As a consequence, more complication and an additional level of routing, so less performance.

One of the advantages of IPv6 is the support of IPSec authentication and encryption (AH, ESP) right in the extension headers, which makes it natively support IPv6 multicast.

In this lab we will be using IPv6 IPSec site-to-site protection using VTI to natively support IPv6 multicast.

The configuration involves three topics: IPv6 routing, IPv6 IPSec and IPv6 multicast. Each process is built on the top the previous one, so before touching IPsec, make sure you have local connectivity for each segment of the network and complete reachability through IPv6 routing.

Next step, you can move to IPv6 IPSec and change routing configuration accordingly (through VTI).

IPv6 multicast relies on a solid foundation of unicast reachability, so once you have routes exchanged between the two sides through the secure connection you can start configuring IPv6 multicast (BSR, RP, client and server simulation).

Picture1: Lab topology

IPv6 multicast over IPv6 IPSec VTI

Lab outline

  • Routing
    • OSPFv3
    • EIGRP for IPv6
  • IPv6 IPSec
    • Using IPv6 IPSec VTI
    • Using OSPFv3 IPSec security feature
  • IPv6 Multicast
    • IPv6 PIM BSR
  • Offline lab
  • Troubleshooting cases
  • Performance testing

Routing

Note:
IPv6 Routing relies on link-local addresses, so for troubleshooting purpose, link-local IPs are configured to be similar to their respective global addresses, so they are easily recognisable. This will be of a tremendous help during troubleshooting. Otherwise you will find yourself trying to decode the matrix : )

OSPFv3

Needs an interface configured with IPv4 address for Router-id

OSPFv3 offloads security to IPv6 native IPv6, so you can secure OSPFv3 communications on purpose: per- interface or per-area basis.
  Table1: OSPFv3 configuration

  R2 R1
IPv6 routing processes need IPv4-format router ids ipv6 router ospf 12
router-id 2.2.2.2
 ipv6 router ospf 12
router-id 1.1.1.1
Announce respective LAN interfaces interface FastEthernet0/1
ipv6 ospf 12 area 22
interface FastEthernet0/1
ipv6 ospf 12 area 11 
Disable routing on the physical BTB connection to avoid RPF failure interface FastEthernet0/0
 ipv6 ospf 12 … 
interface FastEthernet0/0
 ipv6 ospf 12 …
IPv6 gateways exchange routes through the VTI encrypted interface interface Tunnel12
ipv6 ospf network point-to-point
ipv6 ospf 12 area 0
interface Tunnel12
ipv6 ospf network point-to-point
ipv6 ospf 12 area 0
Set the ospf network type on loopback interfaces if you want to advertise masks other that 128-length interface Loopback0
ipv6 ospf network point-to-point
ipv6 ospf 12 area 0
interface Loopback0
ipv6 ospf network point-to-point
ipv6 ospf 12 area 0
Table2: EIGRP for IPv6 configuration
  R2 R1
IPv6 routing processes need IPv4-format router ids ipv6 router eigrp 12
eigrp router-id 2.2.2.2
ipv6 router eigrp 12
eigrp router-id 1.1.1.1
Announce respective LAN interfaces interface FastEthernet0/1
ipv6 eigrp 12
interface FastEthernet0/1
ipv6 eigrp 12
Disable routing on the physical BTB connection to avoid RPF failure interface FastEthernet0/0
ipv6 eigrp 12
interface FastEthernet0/0
ipv6 eigrp 12
IPv6 gateways exchange routes through the VTI encrypted interface interface Tunnel12
ipv6 eigrp 12
interface Tunnel12
ipv6 eigrp 12
Set the ospf network type on loopback interfaces if you want to advertise masks other that 128-length interface Loopback0
ipv6 ospf network point-to-point
ipv6 ospf 12 area 0
interface Loopback0
ipv6 ospf network point-to-point
ipv6 ospf 12 area 0
Enable EIGRP process ipv6 router eigrp 12
no shutdown
ipv6 router eigrp 12
no shutdown

In case you want to configure EIGRP for IPv6:

– No shutdown inside EIGRP configuration mode

– Similarly to OSPFv3, we need an interface configured with IPv4 address for Router-id

IPv6 IPSec

  • Using IPv6 IPSec VTI
Table3: IPSec configuration
  R1 R2
Set the type of ISAKMP authentication crypto keyring keyring1
pre-shared-key address ipv6 2001:DB8::2/128 key cisco
crypto keyring keyring1
pre-shared-key address ipv6 2001:DB8::1/128 key cisco
  crypto isakmp key cisco address ipv6 2001:DB8::2/128 crypto isakmp key cisco address ipv6 2001:DB8::1/128
ISAKMP profile crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
lifetime 3600
crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
lifetime 3600
Transform sets: symmetric encryption and signed hash algorithms crypto ipsec transform-set 3des ah-sha-hmac esp-3des crypto ipsec transform-set 3des ah-sha-hmac esp-3des
  crypto ipsec profile profile0
set transform-set 3des
crypto ipsec profile profile0
set transform-set 3des
Tunnel mode and bind the ipsec profile interface Tunnel12
ipv6 address FE80::DB8:12:1 link-local
ipv6 address 2001:DB8:12::1/64
tunnel source FastEthernet0/0
tunnel destination 2001:DB8::2
tunnel mode ipsec ipv6
tunnel protection ipsec profile profile0
interface Tunnel12
ipv6 address FE80::DB8:12:2 link-local
ipv6 address 2001:DB8:12::2/64
tunnel source FastEthernet0/0
tunnel destination 2001:DB8::1
tunnel mode ipsec ipv6
tunnel protection ipsec profile profile0
Make sure to not advertise the routes through the physical interface to avoid RPF failures (when the source of the multicast traffic is reached from an different interface than the one provided by the RIB) interface FastEthernet0/0
ipv6 address FE80::DB8:1 link-local
ipv6 address 2001:DB8::1/64
ipv6 enable
interface FastEthernet0/0
ipv6 address FE80::DB8:2 link-local
ipv6 address 2001:DB8::2/64
ipv6 enable
 

Here is a capture of the traffic (secured) between R1 and R2 gateways

Picture2: Wireshark IPv6 IPSec trafic capture

IPv6-IPSec-VTI

What could go wrong?

– Encryption doesn’t match

– Shared key doesn’t match

– Wrong ISAKMP peers

– ACL in the path between the 2 gateways blocking gateways IPs or protocol 500

– IPSec profile no assigned to the tunnel int ( tunnel protection ipsec profile < …>)

– Ipsec Encryption and/or signed hashes don’t match.

  • Using OSPFv3 IPSec security feature

You still can use IPv6 IPSec to encrypt and authenticate only OSPF per-interface basis.

OSPFv3 will use the IPv6-enabled IP Security (IPsec) secure socket API.

R1

interface FastEthernet0/0
ipv6 ospf 12 area 0
ipv6 ospf encryption ipsec spi 256 esp 3des 123456789A123456789A123456789A123456789A12345678 md5 123456789A123456789A123456789A12

R2

interface FastEthernet0/0
ipv6 ospf 12 area 0
ipv6 ospf encryption ipsec spi 256 esp 3des 123456789A123456789A123456789A123456789A12345678 md5 123456789A123456789A123456789A12

Picture4: Wireshark traffic capture – OSPFv3 IPSec feature :

ipv6-ospf-feature

Note only OSPFv3 traffic is encrypted

IPv6 Multicast

IPv6 PIM BSR

The RP (Rendez-vous point) is the point where multicast server offer meets member’s demand.

First hop routers build (S,G) source trees with candidate RPs and register directly connected multicast sources.

Candidate- RPs announce themselves to candidate-BSRs, and the latter announce the inf. to all PIM routers.

All PIM routers looking for a particular multicast group learn Candidate RP IP addresses from BSR and build (*, G) shared trees.

Table4: Multicast configuration

  R1(candidate RP) R2(candidate BSR)
Enable multicast routing ipv6 multicast-routing ipv6 multicast-routing
R1 announced as BSR candidate ipv6 pim bsr candidate bsr 2001:DB8:10::1  
R2 announced as RP candidate   ipv6 pim bsr candidate rp 2001:DB8:20::2
Everything should be routed through the tunnel interface, to be encrypted ipv6 route ::/0 Tunnel12 FE80::DB8:12:2 ipv6 route ::/0 Tunnel12 FE80::DB8:12:1
For testing purpose, make one router join a multicast traffic and ping it from a LAN router on the other side or you can opt for more fun by running VLC on one host to read a network stream and stream a video from a host on the other side.   interface FastEthernet0/1
ipv6 mld join-group ff0E::5AB

Make sure that:

  • At least one router is manually configured as a candidate RP
  • At least one router is manually configured as a candidate BSR
During multicasting of the traffic, sll PIM routers knows about the RP and the BSR

– (*,G) shared tree is spread over PIM routers from the last hop router (connected to multicast members).

– (S,G) source tree is established between the first hop router (connected to the multicast server) and the RP.

– The idea behind IPv6 PIM BSR is the same as in IPv4; here an animation explaining the process for IPv4.

Let’s check end-to-end multicast streaming:

Before going to troubleshooting here is the offline lab with all commands:

Troubleshooting

If something doesn’t work and you are stuck, isolate the area of work and inspect each process separately step by step.

Check each step using “show…” commands, so you know each time what you are looking for to spot what is wrong.

“sh run” and script comparison technique is limited by the visual perception capability which is illusory and far from being reliable.

Common routing issues

– Make sure you have successful back-to-back connectivity everywhere.

– With EIGRP for IPv6 make sure the process is enabled.

– If routing neighbors are connected through NBMA network, make sure to enable pseudo broadcasting and manually set neighbor commands.

Common IPSec issues

– ISAKMP phase

– Wrong peer

– Wrong shared password

– Not matching isakmp profile

– IPSec phase

– Not matching ipsec profile

Common PIM issues

– If routing neighbors are connected through NBMA network, make sure C-RPs and C-BSRs are locate on the main site.

– Issue with the client: => no (*,G)

– MLD query issue with the last hop.

– Last hop PIM router cannot build the shared tree.

– Issue with RP registration  => no (S,G)

– Multicast server MLD issue with the 1st hop router

– 1st hop router cannot register with th RP.

– Issue with C-BSR candidate doesn’t advertise RP inf. to PIM routers (BSRs collect all candidate RPs and announce them to all PIM routers to choose the best RP for each group)

– Issue with C-RP candidate doesn’t announce themselves to C-BSRs (RPs announce to C-BSRs which multicast groups they are responsible for)

-RPF failure (the interface used to reach the multicast source, through RIB, is not the interface sourcing the multicast traffic)

Picture5: RPF Failure

Replace test case 6 with RPF failure (enable PIM & routing through physical int.)

Table5: troubleshooting cases
Case Description Simulated wrong configuration Correct configuration
ISAKMP policy, encryption key mismatch crypto isakmp policy 10
encr aes
crypto isakmp policy 10
encr 3des
2 ISAKMP policy, Hash algorithm mismatch crypto isakmp policy 10
Hash sha
crypto isakmp policy 10
Hash md5 
3 Wrong ISAKMP peer crypto isakmp key cisco address ipv6 2001:DB8::3/128 crypto isakmp key cisco address ipv6 2001:DB8::2/128 
4 Wrong ISAKMP key crypto isakmp key cisco1 address ipv6 2001:DB8::2/128 crypto isakmp key cisco address ipv6 2001:DB8::2/128 
5 Wrong tunnel destination interface Tunnel12
tunnel destination 2001:DB8::3
interface Tunnel12
tunnel destination 2001:DB8::2 
6 Wrong tunnel source interface Tunnel12
tunnel source FastEthernet0/1
interface Tunnel12
tunnel source FastEthernet0/0
 

For more details about each case, refer to the offline lab below, you will find an extensive coverage of all important commands along with debug for each case:

Performance testing

Three cases are tested: multicast traffic between R1 and R2 is routed through:

– Physical interfaces (serial connection): MTU=1500 bytes

– IPv6 GRE: MTU=1456 bytes

– IPv6 IPSec VTI: MTU=1391 bytes

The following tests are performed using iperf in GNS3 lab environment, so results are to keep relative.

Picture6: Iperf testing

perfs

References

http://www.faqs.org/rfcs/rfc6226.html

http://tools.ietf.org/html/rfc5059

http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-multicast.html#wp1055997

https://supportforums.cisco.com/docs/DOC-27971

http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-tunnel_external_docbase_0900e4b1805a3c71_4container_external_docbase_0900e4b181b83f78.html

http://www.cisco.com/web/learning/le21/le39/docs/TDW_112_Prezo.pdf

http://networklessons.com/multicast/ipv6-pim-mld-example/

http://www.gogo6.com/profiles/blogs/ietf-discusses-deprecating-ipv6-fragments

http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-01

https://datatracker.ietf.org/doc/draft-bonica-6man-frag-deprecate

http://blog.initialdraft.com/archives/1648/

IPv6 BGP synchronization


If you have been dealing with BGP under IOS < 12.0, you know something about BGP synchronization.

This post is driven by three reasons…nostalgia is not one of them : )

  1. BGP synchronization illustrates the difference of BGP with the traditional concept of interior routing protocols like OSPF, RIP or EIGRP.
  2. With ever-growing transition to IPv6, I wanted to test the concept of synchronization with IPv6.
  3. You need to work out your brain muscles and be ready to deal with anything in the CCIE exam where your problem-solving skills will be tested more than your knowledge of best practices.

So let’s brush up our knowledge of the concept with a brief definition of BGP:

BGP is used to advertise NLRI (Network Layer reachability information) between ASs (Autonomous Systems) and it relies on TCP (179) for reliability of the communications. BGP is an attribute-based path-vector protocol.

BGP synchronization states that, if your autonomous system passes traffic from another AS to a third AS (transit), eBGP speaker should not advertise a route before all the routers in your AS have learned about the NLRI via IGP. So BGP will wait until IGP has propagated the route within the AS.

If not done properly, the transit AS will turn into a route black hole.

Here is a small animation illustrating the concept:

Animation

The solution is mutual redistribution of routes between BGP and the IGP.

Nowadays, BGP is running on all routers in autonomous system transit paths, so synchronization is disabled by default.

This allows you to carry fewer routes in your IGP and allow BGP to converge more quickly.

IPv6 configuration

Topology

Router R1:

Redistribution from OSPF TO BGP

router bgp 65012
address-family ipv6 unicast
 redistribute ospf 125
!
route-map RM6_OSPF_TO_BGP match external 2
route-map RM6_OSPF_TO_BGP
permit 10 match ipv6 address ACL6_OSPF_TO_BGP
!
ipv6 access-list ACL6_OSPF_TO_BGP
permit ipv6 2001:db8:209::/64 any log
permit ipv6 2001:db8:23::/64 any log

Redistribution from BGP to OSPF

route-map RM6_BGP_TO_OSPF permit 10
match ip address ACL6_BGP_TO_OSPF
!
ip access-list standard ACL6_BGP_TO_OSPF
permit ipv6 2001:db8:14::/64 any log
!
ipv6 router ospf 125
redistribute bgp 65012 subnets route-map RM6_BGP_TO_OSPF

Redistribution from BGP to OSPF

R1# sh ipv6 route
IPv6 Routing Table - 8 entries
…
C   2001:DB8:14::/64 [0/0]
via ::, FastEthernet0/1
L   2001:DB8:14::1/128 [0/0]
via ::, FastEthernet0/1
C   2001:DB8:15::/64 [0/0]
via ::, FastEthernet0/0
L   2001:DB8:15::1/128 [0/0]
via ::, FastEthernet0/0
O   2001:DB8:25::/64 [110/20]
via FE80::15:5, FastEthernet0/0
B   2001:DB8:40::/64 [20/0]
via FE80::14:4, FastEthernet0/1
OE2 2001:DB8:209::/64 [110/1] via FE80::15:5, FastEthernet0/0
L FF00::/8 [0/0] via ::, Null0 
R1#

R2:

Redistribution from BGP to OSPF

route-map RM6_BGP_TO_OSPF permit 10
match ipv6 address ACL6_BGP_TO_OSPF
!
ipv6 access-list  ACL6_BGP_TO_OSPF
permit 2001:db8:209::/64 any log
permit 2001:db8:23::/64 any log
!
ipv6 router ospf 125
redistribute bgp 65012 route-map RM6_BGP_TO_OSPF

Redistribution from OSPF to BGP

router bgp 65012
address-family ipv6 unicast
redistribute ospf 125 route-map RM6_OSPF_TO_BGP match external 2
route-map RM6_OSPF_TO_BGP permit 10

match ipv6 address ACL6_OSPF_TO_BGP 

!

ipv6 access-list ACL6_OSPF_TO_BGP permit 2001:db8:14::/64 any log

The presence of prefix 2001:DB8:40::/64 originated in AS 65040 (iBGP administrative distance = 200) in the IGP table (OSPFv3 administrative distance =110) means that the core IGP has synchronized the prefix.

R2#sh bgp ipv6 unicast  2001:DB8:40::/64
BGP routing table entry for 2001:DB8:40::/64, version 4
Paths: (2 available, best #1, table Global-IPv6-Table)
Advertised to update-groups:
1    2
Local
:: from 0.0.0.0 (2.2.2.23)
Origin incomplete, metric 1, localpref 100, weight 32768, valid, sourced, best
65040
2001:DB8:15::1 (metric 20) from 2001:DB8:15::1 (1.1.1.14)
Origin IGP, metric 0, localpref 100, valid, internal,
synchronized
R2#



R2# sh ipv6 route
IPv6 Routing Table - 8 entries
…
O   2001:DB8:15::/64 [110/20]
via FE80::25:5, FastEthernet0/0
C   2001:DB8:23::/64 [0/0]
via ::, FastEthernet0/1
L   2001:DB8:23::2/128 [0/0]
via ::, FastEthernet0/1
C   2001:DB8:25::/64 [0/0]
via ::, FastEthernet0/0
L   2001:DB8:25::2/128 [0/0]
via ::, FastEthernet0/0
OE2 2001:DB8:40::/64 [110/1]
via FE80::25:5, FastEthernet0/0

B 2001:DB8:209::/64 [20/0]

via FE80::23:3, FastEthernet0/1

L FF00::/8 [0/0]

via ::, Null0

R2#

 

From R5 core IGP router you can notice that OSPFv3 is synchronized with transit route prefixes from AS 64030 and AS 64040.

R5:

R5#sh ipv6 route
IPv6 Routing Table - 7 entries
…
C   2001:DB8:15::/64 [0/0]
via ::, FastEthernet0/0
L   2001:DB8:15::5/128 [0/0]
via ::, FastEthernet0/0
C   2001:DB8:25::/64 [0/0]
via ::, FastEthernet0/1
L   2001:DB8:25::5/128 [0/0]
via ::, FastEthernet0/1
OE2 2001:DB8:40::/64 [110/1] via FE80::15:1, FastEthernet0/0 OE2 2001:DB8:209::/64 [110/1] via FE80::25:2, FastEthernet0/1
L FF00::/8 [0/0] via ::, Null0 
R5#

Offline lab

With the offline lab you will have an idea about the network behavior its states in different test cases.

An extensive range of commands is provided. Both IPv6 and IPv4 BGP synchronization are configured in the offline lab.

I hope you will find it useful. Suggestions and critics are welcome.

IPv6 routing protocol redistribution


Though the transition period from IPv4 to IPv6 is going to last for a long time in which both protocols will coexist, we shouldn’t forget that the final goal of IPv6 is to completely replace IPv4.

The best way to gain more experience with the new intricacies and challenges of IPv6 is to test IPv6-based services in the presence of IPv4 as well in a pure IPv6 environment.

The purpose of this lab is to test redistribution between IPv6 routing protocols in an exclusively IPv6 environment.

So I am following exactly the same scenario as the previous post about IPv4 redistribution and I will point out some particularities related to IPv6.

I will start by the problematic design of redistribution from one routing domain into another with lower (better) administrative distance.

If you are not familiar with routing redistribution I strongly recommend you to take a look at the previous post.

Redistribution from one routing domain into another with lower (better) administrative distance:

All the following topologies are subject to the same concept:

As an example, I picked up the case where the source routing domain is EIGRP (internal prefix AD =90 and external prefix AD = 170) and the destination domain is OSPF with a better AD of 110.

Picture 1: Lab High level design


Picture 2: Low level design


Lab content:

1- Redistribution
2- Test connectivity from the BR R1
3- Solutions to overcome suboptimal paths
   3.1- Control paths by controlling the redistribution at the border routers
   3.2- Change the AD per-prefixes
   3.3- Filter prefixes from IGPs into the routing table using inbound distribute-list
   3.4- Prefix summarization
4- Troubleshooting notes5- Conclusion

1- Redistribution

– Redistribute 2001:DB8:123:3333::/64 (external domain/connected) into EIGRP at R3

The network 2001:DB8:123:3333::/64 can be administred with a different IGP than EIGRP or just a directly connected network (a loopback interface in our case).

Because EIGRP differentiates between internal and external prefixes by assigning different Administrative Distances, the prefix 2001:DB8:123:3333::/64 become (D EX) with AD=170.

ipv6 router eigrp 123
router-id 3.3.3.33
no shutdown
redistribute ospf 123 metric 1500 1 100 1 1500 route-map to-eigrp include-connected
!
ipv6 prefix-list ospf-pfx seq 5 permit 2001:DB8:123:3333::/64
!

!

route-map to-eigrp permit 10

match ipv6 address prefix-list ospf-pfx

set tag 3333

Picture 3: redistribution at R3:


– Mutual redistribution between EIGRP & OSPF at R2

For the sake of simplicity, EIGRP prefixes are redistributed into OSPF and vice-verse on R2.

R2:

ipv6 router eigrp 123
router-id 2.2.2.2
no shutdown
redistribute ospf 124 metric 1500 1 100 1 1500 include-connected
!
ipv6 router ospf 124
router-id 2.2.2.22

log-adjacency-changes

redistribute eigrp 123 route-map from-eigrp include-connected

!

!ipv6 prefix-list eigrp-prfx seq 10 permit 2001:DB8:123:2222::/64

ipv6 prefix-list eigrp-prfx seq 20 permit 2001:DB8:123:1111::/64

ipv6 prefix-list eigrp-prfx seq 30 permit 2001:DB8:123:13::/126

ipv6 prefix-list eigrp-prfx seq 40 permit 2001:DB8:123:23::/126

!

ipv6 prefix-list ospf-prfx seq 10 permit 2001:DB8:124:14::/126

ipv6 prefix-list ospf-prfx seq 20 permit 2001:DB8:124:24::/126

ipv6 prefix-list ospf-prfx seq 30 permit 2001:DB8:124:4444::/64

!

!

route-map from-ospf permit 10

match ipv6 address prefix-list ospf-prfx

!

route-map from-eigrp permit 10

match ipv6 address prefix-list eigrp-prfx

!

route-map from-eigrp permit 20

match tag 3333

R1:

ipv6 router eigrp 123
router-id 1.1.1.11
no shutdown
!
ipv6 router ospf 124
router-id 1.1.1.1

Picture4: Mutual redistribution between EIGRP & OSPF at R2


2-Test connectivity from the BR R1

R1#sh ipv6 route
IPv6 Routing Table – 14 entries

OE2 2001:DB8:123:3333::/64 [110/20], tag 3333

via FE80::C003:42FF:FED8:0, FastEthernet0/0


R1#

R1#sh ipv6 eigrp topology
IPv6-EIGRP Topology Table for AS(123)/ID(1.1.1.11)

P 2001:DB8:123:3333::/64, 0 successors, FD is Inaccessible, tag is 3333

via FE80::C002:42FF:FED8:0 (1732352/1706752), FastEthernet0/1


R1#

R1#sh ipv6 eigrp topology
IPv6-EIGRP Topology Table for AS(123)/ID(1.1.1.11)Codes: P – Passive, A – Active, U – Update, Q – Query, R – Reply,
r – reply Status, s – sia Status

P 2001:DB8:124:14::/126, 0 successors, FD is Inaccessible

via FE80::C002:42FF:FED8:0 (1757952/1732352), FastEthernet0/1

P 2001:DB8:123:13::/126, 1 successors, FD is 281600

via Connected, FastEthernet0/1

P 2001:DB8:123:1111::/64, 1 successors, FD is 128256

via Connected, Loopback1

P 2001:DB8:123:3333::/64, 0 successors, FD is Inaccessible, tag is 3333

via FE80::C002:42FF:FED8:0 (1732352/1706752), FastEthernet0/1

P 2001:DB8:123:2222::/64, 1 successors, FD is 435200

via FE80::C002:42FF:FED8:0 (435200/409600), FastEthernet0/1

P 2001:DB8:124:24::/126, 0 successors, FD is Inaccessible

via FE80::C002:42FF:FED8:0 (1757952/1732352), FastEthernet0/1

P 2001:DB8:123:23::/126, 1 successors, FD is 307200

via FE80::C002:42FF:FED8:0 (307200/281600), FastEthernet0/1

P 2001:DB8:124:4444::/64, 0 successors, FD is Inaccessible

via FE80::C002:42FF:FED8:0 (1757952/1732352), FastEthernet0/1

R1#

R1#sh ipv6 route 2001:DB8:123:3333::3/64
IPv6 Routing Table – 14 entries

OE2 2001:DB8:123:3333::/64 [110/20], tag 3333

via FE80::C003:42FF:FED8:0, FastEthernet0/0


R1#

0 Successor(s), FD is 4294967295 (Inaccessible)

Is seen in the EIGRP topology table (IPv4/IPv6). Remember that in a border router each protocol will separately calculate the route to a given destination and submit it to the RIB for the “competition”. The RIB will choose the best route to the prefix+mask and the unique winner protocol is the one with the lowest administrative distances.

Other protocols (losers) not happy with the decision of the RIB will mark their best route in their protocol table

  • EIGRP uses “0 Successor(s), FD is 4294967295 (Inaccessible)”
  • BGP uses “r> (RIB-failure)”

So EIGRP calculated a route to 2001:DB8:123:3333::3/64 directly through R3 and OSPF calculated a route to the same prefix 2001:DB8:123:3333::3/64 through R4.

The RIB will choose OSPF of course because it has better (smaller) administrative distance of 110 against 170 for EIGRP.

R1#ping ipv6 2001:DB8:123:3333::3Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:123:3333::3, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 60/68/84 ms

R1#

R1#traceroute ipv6 2001:DB8:123:3333::3

Type escape sequence to abort.

Tracing the route to 2001:DB8:123:3333::3

1 2001:DB8:124:14::2 32 msec 20 msec 20 msec

2 2001:DB8:124:24::1 48 msec 56 msec 40 msec

3 2001:DB8:123:3333::3 84 msec 32 msec 76 msec

R1#

Picture 5: primary path


The primary path to the prefix 2001:DB8:123:3333::3 is chosen through OSPF domain which is suboptimal because it is 1st redistributed into EIGRP123 then a second time into OSPF124.

We know that during redistribution between different protocols there is inevitable loss of homogeneity of routing information due to deformation of criteria: attributes for BGP, BW and delay for EIGRP, cost for OSPF and hop for RIP.

So what we can do at the border router to influence the choice of the best route to a given prefix?

3- Solutions

  • 3.1- Control paths by controlling the redistribution at the border routers:

    This could be a case where your routing and security policies do not allow to reveal your internal prefixes and traffic to an external domain.

  • 3.2- Change the AD per-prefixes:

    In case you need to guarantee route redundancy for internal traffic even through external domains.

  • 3.3- Filter prefixes from IGPs into the routing table using inbound distribute-list.
  • 3.4- Perform summarization to shorter subnet mask on the source router (remove from the competition by transform)

    So at the destination router receiving the update the longest prefix is selected

3.1- Control paths by controlling the redistribution at the border routers:

Simply do not make redundant or unnecessary redistribution, remember the split horizon between domains with multiple border routers:

DO NOT redistribute a prefix to its domain of origin, if needed, make the metric worse than those internally available.

3.2- Change the AD per-prefixes:

ipv6 router ospf 124
distance ospf external 180

R1(config-rtr)#do route6
IPv6 Routing Table – 14 entries

D 2001:DB8:123:23::/126 [90/307200]

via FE80::C002:42FF:FED8:0, FastEthernet0/1


D 2001:DB8:123:2222::/64 [90/435200]

via FE80::C002:42FF:FED8:0, FastEthernet0/1

EX 2001:DB8:123:3333::/64 [170/1732352], tag 3333

via FE80::C002:42FF:FED8:0, FastEthernet0/1


R1(config-rtr)#

Now prefixes originated from EIGRP, including the redistributed 2001:DB8:123:3333::/64, are reachable through EIGRP, because their OSPF EXT variants have worse administrative distance 180 against 170.

R1(config-rtr)#do sh ipv6 ospf data OSPFv3 Router with ID (1.1.1.1) (Process ID 124)

Type-5 AS External Link States

ADV Router Age Seq# Prefix

2.2.2.22 970 0x80000006 2001:DB8:123:13::/126

2.2.2.22 970 0x80000006 2001:DB8:123:23::/126

2.2.2.22 970 0x80000006 2001:DB8:123:1111::/64

2.2.2.22 970 0x80000006 2001:DB8:123:2222::/64

2.2.2.22 970 0x80000006 2001:DB8:123:3333::/64

R1(config-rtr)#

Let’s simulate a failure in the link between R1 and R3:

R3(config)#int fa0/0
R3(config-if)#sh
R3(config-if)#
*Mar 1 04:26:19.938: %DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 123: Neighbor FE80::C000:42FF:FED8:1 (FastEthernet0/0) is down: interface down
*Mar 1 04:26:21.910: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
*Mar 1 04:26:22.910: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
R3(config-if)#

Now, EIGRP prefixes reachable through OSPF.

R1(config-rtr)#do sh ipv6 route
IPv6 Routing Table – 14 entries

OE2 2001:DB8:123:23::/126 [180/20]
via FE80::C003:42FF:FED8:0, FastEthernet0/0
OE2 2001:DB8:123:2222::/64 [180/20]
via FE80::C003:42FF:FED8:0, FastEthernet0/0

OE2 2001:DB8:123:3333::/64 [180/20], tag 3333

via FE80::C003:42FF:FED8:0, FastEthernet0/0


R1(config-rtr)#

3.3- Filter prefixes from IGPs into the routing table using inbound distribute-list.

Before applying distribute list inbound under OSPF

IPv6 Routing Table – 14 entries

OE2 2001:DB8:123:3333::/64 [110/20], tag 3333
via FE80::C003:42FF:FED8:0, FastEthernet0/0

R1#

R1:

R1(config)#ipv6 router ospf 124
R1(config-rtr)#distribute-list prefix-list 3333_prfx in
R1(config-rtr)#exit
R1(config)#ipv6 prefix-list 3333_prfx deny 2001:DB8:123:3333::/64
R1(config)#ipv6 prefix-list 3333_prfx seq 10 permit ::/0 le 128

Note the default route used in the prefix-list ::/0 le 128 is different from the one used in IPv6 default static route abd the routing table ::/0

R1(config)#do route6
IPv6 Routing Table – 14 entries

EX
2001:DB8:123:3333::/64 [170/1732352], tag 3333
via FE80::C002:42FF:FED8:0, FastEthernet0/1

R1(config)#

3.4- Prefix summarization:

Let’s perform summarization of the prefix 2001:DB8:123:3333::3 on R3 to a shorter mask length of /60 before announcing it to R4 then to R1.

R4 before summarization:

R4#route6
IPv6 Routing Table – 14 entries

via FE80::C001:42FF:FED8:0, FastEthernet0/1
OE2
2001:DB8:123:3333::/64 [110/20], tag 3333

R4#

R1 before summarization:

R1(config-rtr)#do route6
IPv6 Routing Table – 15 entries

EX
2001:DB8:123:3333::/64 [170/1732352], tag 3333
via FE80::C002:42FF:FED8:0, FastEthernet0/1

R1(config-rtr)#

To keep the routing information consistent inside OSPF area, summarization has to be done at the ABR or ASBR.

Summarization on R2 (ASBR router):

R2(config)#no router ospf 124
R2(config-rtr)#summary-prefix 2001:DB8:123:3333::3/60

Now let’s take a look again at the routing table of R1 and R4:

R4#route6
IPv6 Routing Table – 14 entries

OE2 2001:DB8:123:3330::/60 [110/20]
via FE80::C001:42FF:FED8:0, FastEthernet0/1

R4#

R1(config-rtr)#do route6
IPv6 Routing Table – 16 entries

OE2 2001:DB8:123:3330::/60 [110/20]

via FE80::C003:42FF:FED8:0, FastEthernet0/0

EX 2001:DB8:123:3333::/64 [170/1732352], tag 3333

via FE80::C002:42FF:FED8:0, FastEthernet0/1


R1(config-rtr)#

R1 has received the summary address 2001:DB8:123:3330::/60 and consider it as different from 2001:DB8:123:3333::/64 received through EIGRP.

To forward traffic, RIB will chooses the longest match i.e. 2001:DB8:123:3333::3

R1#traceroute ipv6 2001:DB8:123:3333::3
 
Type escape sequence to abort.

Tracing the route to 2001:DB8:123:3333::3

1 2001:DB8:123:3333::3 60 msec 24 msec 60 msec

R1#

 

4-Troubleshooting notes

*) Redistribution doesn’t work :
– Check typing errors in route-maps and prefix-lists names because IOS will not alert you in case of the following errors during redistribution:
– Wrong route map name
– Wrong ACL/prefix-list name inside the route-map
– Default metric not configured (EIGRP/RIP/IS-IS)
– Check whether the prefix you want to redistribute exists in the RIB of the border router and belongs to the IGP source of the redistribution.
– IPv6 routing requires only link-local addresses (fe80::/10) to a establish the relationships within a segment, even if the mask or the subnet doesn’t match.

The discrepancies will emerge later. So make sure to carefully plan and deploy your address scheme.

*) EIGRP for IPv6 is by default shut down

*) Misconfiguration errors:

– Many IPv6 commands are the same as for IPv4, the keyword “ip” is replaced by “ipv6”. Nevertheless, what is easy to do can also be easy not to do. After a couple of hours with the contrast of the CLI, you will start glazing over J and you will notice that the device doesn’t react to your commands.

That’s a sign that something intrinsically wrong, like typing in the wrong router console, copy/past wrong fragments or typing “ip” instead of “ipv6.”

5- Conclusion

Following some techniques used to manipulate internal routing protocol paths:

1- Control what prefixes and where to redistribute.

2- Manipulate AD per-prefix (be careful with this technique!)

3- Filter prefixes from IGPs into the routing table using inbound distribute-list.

4- Summarization to shorter subnet mask on the source router.


BGP Backdoor


In this post I would like to share with you my experience with BGP backdoors along with some interesting observations related to the configuration.

Picture 1: lab topology

Our lab topology (picture1) illustrates two client autonomous systems connected to a backbone through eBGP (external).

The backdoor link will be the direct connection between AS 64030 and AS 64023

Backdoors can be motivated by some business needs like merging, acquisition, temporary collaboration between companies or technical needs like backup for example.

Due to the transient nature of these links they are routed using an internal routing protocol, in our case it is EIGRP.

Recall notes:

To understand the issue that lurks behind backdoors we need to understand some routing concepts.

BGP is a routing protocol used to route between Autonomous Systems. So BGP is not intended to ensure prefix connectivity, this is the role of IGP (internal routing protocols like OSPF, EIGRP or RIP).

In the case the same prefix is advertised through multiple routing protocols an election will take place to choose the best protocol.

Here where Administrative Distances are called into play to set a priority or preference for each protocol. The higher the Administrative Distance the less preferable is the protocol.

unreachable => 255Internal BGP (iBGP) => 200External EIGRP => 170

RIP => 120

OSPF => 110

Internal EIGRP => 90

External BGP (eBGP) = 20

Summary EIGRP => 5

Static route => 1

Directly connected => 0

The key concept behind that particular distribution of AD is that there is a big difference between routing internal prefixes inside a single domain and routing external prefixes (between different routing domain)

The same concept is valid for a single protocol (or should be).

We know that a prefix announced internally is more preferable that the same prefix coming from redistribution.

This is made easy in EIGRP by having different Administrative Distances, partially in OSPF by having preference for internal then inter-area then inter-domain, but needs to be done manually for RIP.

For example BGP understand that it is not the most qualified to talk about internal connectivity, that’s why iBGP prefixes have an AD of 200 (which is worse than any other IGP)

In the same time the Administrative Distance of external BGP = 20, better than any other IGP because BGP is the king, the champion of inter Autonomous system routing.

And for the same reasons OSPF do NOT redistribute by default external type1/type2 prefixes to BGP and by default BGP redistribute ONLY eBGP (external BGP) prefixes to other IGP.

In our case the border routers R2 and R3 will receive prefixes from External BGP (eBGP) = 20 and Internal EIGRP => 90

So if the prefixes 30 are advertised through both protocols, eBGP will be selected to be installed in the RIB.

Picture2: prefix installation in RIB between BGP and EIGRP

Picture 3: prefixes 30 at the Border router R2:

So far everything works according to the previously mentioned concepts, and namely that’s the issue.

Whatever the reason behind this backdoor link the goal is to make the traffic for prefixes 30 take the direct back-to-back connection between AS 64030 and 64023.

So what we need to do is to create an exception to the rule:

Theoretically there are 2 solutions:

A – Manually
    1- Making the originator router R3 not advertising backdoor prefixes
    2- Play with AD at R2 to make backdoor more preferable. This NOT recommended except when you are asked to do so (strict routing policies or CCIE exam P-:))

B- Using IOS BGP backdoor feature.

Looks like distinct solutions? Let’s see!

Enough of concepts, let’s go to the lab for more details.

Configuration:

Backdoor command: network <X.X.X.X> mask <Y.Y.Y.Y> backdoor

That’s all!

Let’s begin by applying the command on the border router R3 for prefixes 30

R3(config)#router bgp 64023
R3(config-router)#net 30.0.0.0 mask 255.255.255.0 backdoor
R3(config-router)#net 30.0.1.0 mask 255.255.255.0 backdoor

R3(config-router)#net 30.0.2.0 mask 255.255.255.0 backdoor

R3(config-router)#net 30.0.3.0 mask 255.255.255.0 backdoor

And I will trigger an on-demand outbound advertisement using soft reset

clear ip bgp 4.4.4.4 soft out
R3#
*Mar 1 22:46:20.954: BGP(0): 4.4.4.4 send UPDATE (format) 30.0.2.0/24, next 3.3.3.3, metric 0, path Local
*Mar 1 22:46:20.962: BGP(0): 4.4.4.4 send UPDATE (prepend, chgflags: 0x0) 30.0.1.0/24, next 3.3.3.3, metric 0, path Local

*Mar 1 22:46:20.966: BGP(0): 4.4.4.4 send UPDATE (prepend, chgflags: 0x0) 30.0.0.0/24, next 3.3.3.3, metric 0, path Local

*Mar 1 22:46:21.070: BGP(0): updgrp 1 – 4.4.4.4 updates replicated for neighbors:

R3#

So R3 has advertised backdoor prefixes through eBGP…

We can verify this on R2:

R2 (config-router)#do sh ip route

30.0.0.0/24 is subnetted, 3 subnets

B 30.0.2.0 [20/0] via 1.1.1.1, 00:00:31

B 30.0.0.0 [20/0] via 1.1.1.1, 00:00:31

B 30.0.1.0 [20/0] via 1.1.1.1, 00:00:31

R2(config-router)#

That’s not what Cisco states in the documentation??!?!?!

http://www.cisco.com/en/US/docs/ios/iproute_bgp/configuration/guide/irg_basic_net_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1117226

Interestingly enough, only if I reboot R3 the router will not advertise these prefixes and R2 will receive only EIGRP prefixes and the issue is resolved. (Solution A-1)

(The following RIB and BGP tables are the result of configuring backdoor on R3 and rebooting it)

R2#sh ip bgp
BGP table version is 10, local router ID is 20.0.2.1
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 Next Hop Metric LocPrf Weight Path

*> 10.0.0.0/24 1.1.1.1 0 0 64014 i

*> 10.0.1.0/24 1.1.1.1 0 0 64014 i

*> 10.0.2.0/24 1.1.1.1 0 0 64014 i

*> 20.0.0.0/24 0.0.0.0 0 32768 i

*> 20.0.1.0/24 0.0.0.0 0 32768 i

*> 20.0.2.0/24 0.0.0.0 0 32768 i

*> 40.0.0.0/24 1.1.1.1 0 64014 i

*> 40.0.1.0/24 1.1.1.1 0 64014 i

*> 40.0.2.0/24 1.1.1.1 0 64014 i

R2#

No prefixes 30

R2#sh ip route

30.0.0.0/24 is subnetted, 3 subnets

D 30.0.2.0 [90/2297856] via 172.16.23.3, 2d13h, Serial1/2

D 30.0.0.0 [90/2297856] via 172.16.23.3, 2d13h, Serial1/2

D 30.0.1.0 [90/2297856] via 172.16.23.3, 2d13h, Serial1/2

R2#

Now, let’s go further and configure backdoor feature on R2 even though networks 30 are not connected.

R2(config)#router bgp 64023
R2(config-router)#net 30.0.0.0 mask 255.255.255.0 backdoor
R2(config-router)#net 30.0.1.0 mask 255.255.255.0 backdoor

R2(config-router)#net 30.0.2.0 mask 255.255.255.0 backdoor

Now let’s check again R2 BGP & RIB tables

R2#sh ip bgp

r>
30.0.0.0/24 1.1.1.1 0 64014 64030 i

r>
30.0.1.0/24 1.1.1.1 0 64014 64030 i

r>
30.0.2.0/24 1.1.1.1 0 64014 64030 i


R2#

R2#sh ip route

30.0.0.0/24 is subnetted, 3 subnets

D 30.0.2.0 [90/2297856] via 172.16.23.3, 00:00:13, Serial1/2

D 30.0.0.0 [90/2297856] via 172.16.23.3, 00:00:19, Serial1/2

D 30.0.1.0 [90/2297856] via 172.16.23.3, 00:00:16, Serial1/2

R2#

That’s exactly what we were looking for.

More detailed BGP inf.

R2#sh ip bgp 30.0.0.0
BGP routing table entry for 30.0.0.0/24, version 20
Paths: (1 available, best #1, table Default-IP-Routing-Table, RIB-failure(17))

Flag: 0x820

Not advertised to any peer

64014 64030

1.1.1.1 from 1.1.1.1 (1.1.1.1)

Origin IGP, localpref 100, valid, external, best

R2#

Note the RIB-failure

This is when BGP fail to install its best selection into the routing table (or maximum prefix number is configured or even in some cases IOS failure)

In our case it is caused by a better routing protocol, and knowing that EIGRP AD = 90 and eBGP =90 we can conclude that IOS manipulated them accordingly to make EIGRP the winner. (Solution A-2)

Conclusion:

We have seen that backdoor feature (solution B) accomplishes the work in 2 different ways:

1- Not advertise prefixes through eBGP (solution A-1) if configured only on the originating router and this last is rebooted.

2- Continue to advertise prefixes and manipulate Administrative distances if configured on both Border routers delimiting the backdoor connection (solution A-2).

Multicast mtrace command


This short post illustrates how the cisco command “mtrace” works.

Let’s consider the following topology  :

Multicast topology with successful RPF check.

With the multicast source at 10.0.0.1 and a multicast member at 20.0.0.1 requesting multicast content from 10.0.0.1.

10.0.0.1 and 20.0.0.1 can reach each other ONLY through R5-R2-R4 which also enabled for PIM.

According to : http://www.cisco.com/en/US/docs/ios/12_3/ipmulti/command/reference/ip3_m1g.html#wp1068645

Usage Guidelines

The trace request generated by the mtrace command is multicast to the multicast group to find the last hop router to the specified destination. The trace then follows the multicast path from destination to source by passing the mtrace request packet via unicast to each hop. Responses are unicast to the querying router by the first hop router to the source. This command allows you to isolate multicast routing failures.

mtrace

Let’s execute mtrace command from R1 :

mtrace 10.0.0.1 20.0.0.1 239.1.1.1

This will send multicast traffic from 10.0.0.1(multicast source) to 20.0.0.1 (multicast member) and then query back the source starting from the last hop router (directly connected to the member)

R1#mtrace 10.0.0.1 20.0.0.1 239.1.1.1Type escape sequence to abort.Mtrace from 10.0.0.1 to 20.0.0.1 via group 239.1.1.1From source (?) to destination (?)Querying full reverse path…0  20.0.0.1  ————> where mtrace started tracing back toward the multicast traffic source 10.0.0.1

-1  192.168.24.5 PIM  [10.0.0.0/24]  ————> 1st hop toward the multicast traffic source 10.0.0.1

-2  192.168.24.6 PIM  [10.0.0.0/24]  ————> 2nd hop toward the multicast traffic source 10.0.0.1

-3  192.168.52.5 PIM  [10.0.0.0/24]  ————> 3rd hop toward the multicast traffic source 10.0.0.1

-4  192.168.15.6 PIM  [10.0.0.0/24]  ————> last hop to which the multicast traffic source is connected

-5  10.0.0.1 ————> multicast traffic source itself

R1#

R4->R2->R5->R1 is the unicast traffic path

R1->R5->R2->R4 is the multicast traffic path.

This in an indication that the RPF check succeed!

We can also use ping <mgroup> that will generate the multicast traffic toward the multicast member and the result shows confirmation from the multicast member for receiving the multicast traffic.

R1#ping 239.1.1.1 source 10.0.0.1 repeat 9999999Type escape sequence to abort.Sending 9999999, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:Packet sent with a source address of 10.0.0.1Reply to request 0 from 192.168.24.5, 88 ms   ——-> last hop Multicast router is confirming the reception

Reply to request 0 from 192.168.24.5, 92 ms  –——> last hop Multicast router is confirming the reception

Reply to request 1 from 192.168.24.5, 108 ms  ——-> last hop Multicast router  is confirming the reception

Reply to request 1 from 192.168.24.5, 108 ms  ——-> last hop Multicast router  is confirming the reception

Here is the result of mtrace in both cases

Here is  two ad-hoc explanatory videos illustrating both cases of successful and failed RPF check :

Case1 : unicast path = multicast path (successful RPF)

R1#mtrace 10.0.0.1 20.0.0.1 239.1.1.1Type escape sequence to abort.Mtrace from 10.0.0.1 to 20.0.0.1 via group 239.1.1.1From source (?) to destination (?)Querying full reverse path…

0  20.0.0.1

-1  192.168.24.5 PIM  [10.0.0.0/24]

-2  192.168.24.6 PIM  [10.0.0.0/24]

-3  192.168.52.5 PIM  [10.0.0.0/24]

-4  192.168.15.6 PIM  [10.0.0.0/24]

-5  10.0.0.1

R1#

Case2 : unicast path # multicast path (RPF failure)

R1#mtrace 10.0.0.1 20.0.0.1 239.1.1.1Type escape sequence to abort.Mtrace from 10.0.0.1 to 20.0.0.1 via group 239.1.1.1From source (?) to destination (?)

Querying full reverse path…

0  20.0.0.1

-1  192.168.24.5 None No route

R1#

the resulting traceroute request will report all RPF successes in the path back to the multicast source and stop there where an RPF failure.

%d bloggers like this: