EIGRP adjacency using a secondary IP

Consider the following statement from Cisco.com : “Routers do not form EIGRP neighbors over secondary networks.

A Routing-BitsHandbook candidate queried this last week, claiming the statement is misleading and that EIGRP will indeed form an adjacency using a secondary IP address under specific conditions.

Consider the following configuration. R1 connects to R2 using a back-to-back serial connection. Both S1/1 interfaces have a primary and a secondary IP address defined. The EIGRP processes only matches the secondary IP addresses.

R1#
interface Serial1/1
ip address 10.1.1.1 255.255.255.0 secondary
ip address 10.5.1.1 255.255.255.0
!
router eigrp 1
network 10.1.1.1 0.0.0.0
no auto-summary

R2#
interface Serial1/1
ip address 10.0.1.2 255.255.255.0 secondary
ip address 10.5.1.2 255.255.255.0
!
router eigrp 1
network 10.0.1.2 0.0.0.0
no auto-summary

So what do you think will happen in this scenario? Will R1 and R2 become adjacent? Cisco explicitly mentions that a secondary IP address is not used in the EIGRP hello packets, therefore EIGRP neighbors will not become adjacent using secondary IP addresses.
Continue reading “EIGRP adjacency using a secondary IP”

Advertisements

VRF-lite route leaking

The purpose of VRF-lite is to extend the logical separation of two different networks from a MPLS network down to a single CE router, connected to both these networks. It’s called VRF-lite because it is done without running MPLS (LDP/TDP) or MP-BGP between the PE and CE. Traffic is mapped to the VRF assigned to the ingress interface on the CE router.

But VRF-lite could be used without connecting to a MPLS network entirely! Consider what a VRF is?

A VRF is a mechanism used to provide logical separation between routing tables on the same router. It is locally significant to the router. Each interface on a router can only be assigned to one VRF, but a VRF can have multiple interfaces.

So VRF-lite could be used to separate multiple networks using the same equipment. (Not exactly something you should ever plan in a design, but it could be useful to know)

Once you have the separation you needed, you might need a way to selectively bridge that separation to allow communication between the VRF’s.

Assume the following scenario:
Continue reading “VRF-lite route leaking”

Output101- sh run vrf

Now that the hard work is behind me, the awesome holiday has past, I can finally get back to all the outstanding fun stuff. That said I have some good half completed posts are on the way :)

I came across the following command browsing the DOC-CD a couple months back, and I have used it ever since.

sh run vrf [vrf-name]

The show running vrf feature provides the option to display a subset of the running configuration on a router that is linked to a VRF instance. It can be used to display the configuration of a specific VRF or of all VRFs configured on a router. The command is unfortunately only available on the more recent IOS versions, but if available makes life easy.

Continue reading “Output101- sh run vrf”

Troubleshooting BGP

The new focus is of the R&S exam is troubleshooting. And for some reason this is seen as a new topic to study and as a result feared. It is vital to understand why troubleshooting was added to the lab, and why it will possibly be added to other tracks.  Anybody can apply vanilla configs, provided it is done without error, in the correct order, and by avoiding the question pitfalls.

Troubleshooting was introduced by Cisco to give the CCIE certification that edge it needs to seperate the guys that really understand the technologies and those that just learned to configure labs. Troubleshooting is thus NOT a new section! If you understand know each technology, understand its it building blocks, processes and states, troubleshooting should be nothing ‘new’.

That said, once you understand the work, drafting a troubleshooting methodology per technology should be fairly straight forward. A detailed troubleshooting approach is included in each chapter of the Routing-Bits Handbooks.

(Note ‘{ }’ curl-brackets indicate replaceable values, the rest is regex)

Troubleshooting BGP session start-up problems

1- Are you seeing the expected neighbors in a NON ‘idle’ or ‘active’ state?
#sh ip bgp summary

2- Is a sourced telnet to the neighbor address working?
#telnet {peer-ip} 179 /source {src-int-ip}

3- Confirm if the configuration is correct and matching to neighbors configuration?
#sh run | b router bgp

4- If eBGP, is the neighbor directly connected? (Should be 1 hop in the trace)
4.1- If not directly connected is multihop configured?
#trace {peer-ip} source {src-int-ip}
#sh run | i {peer-ip}.*ebgp-multihop

Continue reading “Troubleshooting BGP”