02-29-2012 02:45 AM - edited 03-04-2019 03:28 PM
Hi,
Have an irritation little redistribution problem that I'm unsure of how to solve.
I have an Metro network running ISIS to different locations. There are severals vrf's on different VLAN's with separate ISIS routing processes. ISIS is running in L2-Only There are two redundant hub routers (ME3600X) that are placed centrally.
Connected to each of the ME3600X is an ISR2951 that connects to the internet and handling backup connections over DMVPN. Over those DMVPN tunnels I run MPLS over GRE and routing with BGP. The leaves are IBGP neighbours, and the central ISRs are route-reflectors. In those routers I redistribute from BGP to ISIS and vice versa. The IBGP has an admin distance of 200 and the ISIS route has 115, so in normal operations the ISIS route is installed in the FIB.
My problem is that when an primary connection goes down, I want the backup route via the DMVPN to be redistributed from BGP in to ISIS, and the traffic to go over the DMVPN instead. But what will happen is that when the ISIS route over the primary connection disapear both my ISR's will compete in advertising the route, and as one of the ISR's is advertising it the other one recives it and since ISIS distance are better it will prefer that one, and the other way around. So my routes are coming and going, and everything is unstable. With just one ISR, it works as it should.
I tag the route redistributed in to ISIS, but there is no way to add a incoming distribute list to the interface of the ISR in ISIS, otherwise I might have stopped the route in to the ISR if it was advertised by the other ISR.
Also tried to put the ISR's in different L1 areas in ISIS and redistributed L2 to L1 in the ME3600X with an route-map filtering the routes learned from BGP from the ISR's. That works for failing over, but then I'm stuck on the DMVPN bacause when the primary way comes back again, the L1 learned from the ISR is prefered before the L2 learned from the neighbor over the Metro network.
I was thinking of extending the BGP in to the ME3600X, but I'm think I'm only moving the problem, not solving it. I could of course use EIGRP with distribute-list's between the ME end the ISR, but that would be a very ugly solution...
If anyone has some idea's on how the redistribute an BGP route into ISIS at two points in the network, but ONLY if they not already present, and stop distribute them when route comes back nativley in ISIS, I'd be grateful.
A bit of the relevant config statemens below:
*** ME 3600X ***
!
router isis tagOFFICE
vrf OFFICE
net 49.0820.0001.0100.6304.0001.00
is-type level-2-only
priority 92
metric-style wide
metric 100
!
interface Vlan820
description Metro Network
vrf forwarding OFFICE
ip address 10.63.240.1 255.255.255.128
ip router isis tagOFFICE
ip pim sparse-mode
isis authentication mode md5
isis authentication key-chain ISIS
isis priority 92
!
interface Vlan826
description To ISR (DMVPN)
vrf forwarding OFFICE
ip address 10.63.240.241 255.255.255.252
ip router isis tagOFFICE
ip pim sparse-mode
isis authentication mode md5
isis authentication key-chain ISIS
isis priority 92
!
interface Vlan829
description To Other ME3600X
vrf forwarding OFFICE
ip address 10.63.240.249 255.255.255.248
ip router isis tagOFFICE
ip pim sparse-mode
isis metric 50
isis authentication mode md5
isis authentication key-chain ISIS
isis priority 92
!
*** ISR ***
!
interface GigabitEthernet0/1.826
description To ME3600X
vrf forwarding OFFICE
encapsulation dot1Q 826
ip address 10.63.240.242 255.255.255.252
ip router isis tagOFFICE
isis authentication mode md5
isis authentication key-chain ISIS
!
router isis tagOFFICE
vrf OFFICE
net 49.0820.0001.0100.6303.0217.00
is-type level-2-only
metric-style wide
metric 100
redistribute bgp 65100 metric 10000 route-map REDIST_FROM_BGP
!
router bgp 65100
bgp log-neighbor-changes
bgp listen range 10.63.42.0/24 peer-group 3G
bgp listen limit 1000
neighbor 3G peer-group
neighbor 3G remote-as 65100
neighbor 3G update-source Tunnel1
neighbor 3G timers 15 45
!
address-family ipv4
neighbor 3G activate
exit-address-family
!
address-family vpnv4
neighbor 3G activate
neighbor 3G send-community extended
neighbor 3G route-reflector-client
neighbor 3G next-hop-self
exit-address-family
!
address-family ipv4 vrf OFFICE
redistribute isis tagOFFICE level-2 route-map DENY_FROM_BGP
default-information originate
exit-address-family
!
route-map DENY_FROM_BGP deny 10
match tag 65100
!
route-map DENY_FROM_BGP permit 20
!
route-map REDIST_FROM_BGP permit 10
set tag 65100
!
02-29-2012 03:27 AM
Hello Michael,
>> If anyone has some idea's on how the redistribute an BGP route into ISIS at two points in the network, but ONLY if they not already present, and stop distribute them when route comes back nativley in ISIS, I'd be grateful
if the addressing plane allows for it, you should make BGP routes less specific then ISIS routes by using BGP aggregation of routes on each remote site (with filtering of component routes so they are not advertised over the iBGP mesh).
In this way the ISIS primary routes would be more specific and used when the primary METRO link is restored.
I understand that depending on the number of remote sites this may require a lot of work.
But it is a clean way to deal with a complex scenario like the one you have described if addressing plane allows it.
>> I tag the route redistributed in to ISIS, but there is no way to add a incoming distribute list to the interface of the ISR in ISIS
This happens for the link state nature of ISIS the same applies to OSPF by filtering on interface link state databases could be different on IS nodes in the same area causing problems to SPF (it could lead to routing loops). For this reason it is not supported.
Edit:
adding the two ME 3600 to the iBGP mesh as route reflector client could lead to avoiding redistribution of BGP into IS-IS if you are injecting a default route in ISIS to all the remote sites.
Hope to help
Giuseppe
02-29-2012 03:48 AM
Hmm,
Well that's a solution, got an idea from that.
I can in fact summarize all of the sites in to two routes (10.0.0.0/11 and 10.32.0.0/14), and could route that static out to the ISR's, and if I don't redistribute the BGP routes in to ISIS, the BGP route will turn up in the routing table once it disapers from the ISIS topology, and therefor go over the DMVPN. When it comes back in the ISIS topology it will supress the BGP route in the routing table again, allowing another site going over the backup soultion to reach the site that was previously down over it's Metro connection.
It would have been nice with an dynamic routing redistribution solution, but I guess this is second best...
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide