Redistribute BGP to ISIS at multiple points in the network.

[Michael Famin]

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

!

[Giuseppe Larosa]

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

[Michael Famin]

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...