From: Michael Snyder (msnyder@revolutioncomputer.com)
Date: Fri Feb 13 2004 - 16:37:58 GMT-3
It help to think igp and egp as totally separate things. IGP's are the
main part of the routing table, with little overlap on any particular
router.
Once I get my IGP's done and tested, I don't revisit their configs later
in the lab.
EPG's I think of as overlays riding on top of the igp's, and they may or
may not be in the routing table. It's a separate layer of routing.
Hence when asked into introduce igp routes into bgp, you need to take
measures to correct the routing table.
-----Original Message-----
From: Calton, Doug [mailto:Doug.Calton@getronics.com]
Sent: Friday, February 13, 2004 7:17 AM
To: Michael Snyder; ccielab@groupstudy.com
Subject: RE: A very good use for the bgp distance command.
Sorry - this really confuses me. I understand the basic issues of using
distance command to prevent introducing redistributed routes into the
routing table (i.e. RIP into OSPF causes OSPF to introduce degraded
routes into the table). But this scenario doesn't come together for me.
Are you saying that you are running an IGP to distribute routes to the
loop addresses between two BGP ASes? If so, and if we are
redistributing the IGP into the BGP, then we would generate the EBGP
entry in the same peer as the IGP route - and therefore the same AS, so
the EBGP route would not return to overwrite the EBGP route. The remote
peer should not have an EBGP route to the loop, unless we redistributed
connected on the peer with the loop back, then it might overwrite the
IGP route in a remote AS. Finally, if we have three ASes being serviced
by one IGP, I would think that the third AS would not be preferred in
the BGP process to the local BGP path, and would not be allowed into the
routing table.
Would it be possible to see a more full example of the problem setup?
Thanks!
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Michael Snyder
Sent: Thursday, February 12, 2004 10:01 PM
To: ccielab@groupstudy.com
Subject: A very good use for the bgp distance command.
I just got doing this in a practice lab tonight. Thought I would post a
problem from it.
The lab has loopbacks in the format of 210.x.x.x
210.1.1.1/32
210.2.2.2/32
210.4.4.4/24 (version 1 rip)
210.5.5.5/32
etc.
All my bgp neighbors use loopback peering. Example 210.1.1.1 peers to
210.2.2.2
router bgp 64513
no synchronization
bgp router-id 210.5.5.5
bgp log-neighbor-changes
bgp confederation identifier 200
bgp confederation peers 64512
neighbor internal peer-group
neighbor internal remote-as 64513
neighbor internal update-source Loopback0
neighbor internal route-reflector-client
neighbor 210.2.2.2 peer-group internal
neighbor 210.4.4.4 peer-group internal
neighbor 210.6.6.6 remote-as 64512
neighbor 210.6.6.6 ebgp-multihop 4
neighbor 210.6.6.6 update-source Loopback0
neighbor 210.7.7.7 remote-as 700
neighbor 210.7.7.7 ebgp-multihop 3
neighbor 210.7.7.7 update-source Loopback0
no auto-summary
Here's the rub, one of the requirements is to advertise the loopback
networks into bgp.
I'm using igp to reach my bgp neighbors! As soon as I put the loopback
subnets into bgp, they will go down.
Why? `B 210.8.8.8 [20/0] via 210.7.7.7, 00:02:05` Because the
external AS's will place routes in the routing tables with the admin
distance of 20.
This is just a classic bgp landmine.
Solution, as soon as I saw the requirement I added the following
commands to every router.
access-list 80 permit 210.0.0.0 0.255.255.255
router bgp xxxx
distance 180 210.0.0.0 0.255.255.255 80
end
In English, any bgp routing updates coming from any loopback networks
(which is all my neighbors) set the routes that match access-list 80
(which also is my loopback networks) to the admin distance of 180 (which
is higher than my highest igp eigrp external 170 admin distance)
One note, the distance command uses wildcards, not masks. The ios help
is wrong.
Michael Snyder
Lead Network Engineer
CCNP/DP, CSS1, MCSE NT/2000
Revolution Computer Systems
(270) 443-7400
This archive was generated by hypermail 2.1.4 : Fri Mar 05 2004 - 07:13:49 GMT-3