From: Cecil Wilson (Cecil.Wilson@flextronics.com)
Date: Tue Sep 04 2007 - 13:54:55 ART
Hi GS
- is the EBGP AS peers are mismatch you wil get a message that
includes a hex code, this code is the AS on the near side
What can I use to tell me what the AS is on the far side(peer) if I
don't know.
Are there anyway to tell?
Cecil G. Wilson
IT Network Services
Office: (901) 215-2710
Cell: (901) 601-6201
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Joseph Brunner
Sent: Thursday, August 30, 2007 10:22 PM
To: 'NET HE'; bit.gossip@chello.nl; ccielab@groupstudy.com
Subject: RE: nasty redistribution
Xin He;
I use tagging to prevent route feedback. This will happen when you are
re-distributing one protocol into another in at least two places and the
RECEIVING protocol (like OSPF/RIP) doesn't have a build in mechanism to
detect inferior redistributed routes (EIGRP does this pretty well by
default, with EX = 170).
I use "distance xxx source ACL" when a single path must be preferred
which supersedes what the redistribution decided was the best path on
its own, and the task wont let us touch cost, bandwidth, etc.
Also you will find yourself touch distance often when preferring two
routes (and two sources) from the same protocol (i.e. two ospf paths to
123.0.1.0/24, etc.)
If you find you are stuck on redistribution, DRAW it OUT. THINK like
each router at EACH hop. Consider all information available at each hop,
prefix length, AD, Metric, and as you pointed out, order of learning the
route (what will be in the routing table when the redistribution command
looks for the routes to redistribute)
-Joe
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
NET HE
Sent: Thursday, August 30, 2007 10:24 PM
To: bit.gossip@chello.nl; ccielab@groupstudy.com
Subject: RE: nasty redistribution
Hi,
I was under the same inpression as well. I was always using tagging to
prevent routing loop it there were multiple redistrition points between
2 routing domains. Recently I found a solution, but inputs from group
are very
appreciated.
Since CCIE lab is small, it's very easy to know th biggest metric in a
routing domain, for example, maximum hops in a rip domain, minimum
bandwidth
and biggest acummulated delay in eigrp domain, and biggest acummulated
cost in ospf domain. I would put that biggest metric as default-metric
under the routing protocol. When routes are redistributed from another
routing domain,
all those routes will have the biggest metric at that redistribution
point.
This would simply prevent any routing loop without any tagging.
Best Regards,
Net (Xin) He
>
>Group,
>so far I was under the impression that I could tackle every scenario of
>simple and mutual redistribution by tagging and filtering at
>redistribution points.
>So I focused and practiced a lot to become proficient and familiar with
>this technique.
>Until the simple scenario that I describe below shattered all my
>confidence and pushed me back to square 0 :-( Tagging and filtering is
>not enough: in some cases it doesn't work; in some cases admin
>disctance must be manipulated.
>
>The problem with this simple network is the redistribution of R7 lo0
>170.1.7.7
>from RIP to OSPF via 2 distribution points: R5 and R6. In normal
>condition the network is stable in the following status:
>- either R5 or R6, whoever is faster, redistributes 170.1.7.7 from RIP
>to OSPF; let's assume R6 is faster
>- R6 will redistribute 150.1.7.7 into OSPF and keep the original RIP
>route in its routing table R6#show ip route | i 170.1.7.7
>R 170.1.7.7/32 [120/1] via 170.1.200.7, 00:00:23, FastEthernet0/0
>
>- R5 instead learns 170.1.7.7 via OSPF so that the OSPF route
>overwrites the RIP route due to better admin distance R5#show ip route
>| i 170.1.7.7
>O E2 170.1.7.7/32 [110/20] via 170.1.100.9, 00:17:30, Serial1/0.1
>
>- the tagging that I put in place prevents the route from
ricirculating:
>the
>network is perfectly stable, even if maybe routing is not optimal but
>who cares now.....
>
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>The fun starts if I shutdown the OSPF session between R5 and R2, for
>instance putting passive one interface long enogh for R5 to re-learn
>the route via RIP from R7. At this point, if we reestablish OSPF, both
>R5 and R6 try to redistribute the route from RIP to OSPF and 170.1.7.7
>ping-pongs for ever between R5 and R6.
>
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>The first nasty thing here is that I would have not spotted this
>condition at the real lab because in normal condition the network is
>stable and even after a reload the network comes up stable. Only what I
>described above can trigger the instability.
>The second nasty thing is that now I am back to the original question:
>when should I use tagging? When admin-distance? When both?
>In this case I guess both are needed!
>
>The reason why I tried to avoid manipulating admin distance so far is
>the
>following:
>
>Let's say that to solve the instability here I increase the admin
>distance of OSPF external to 121: the problem of 170.1.7.7 is solved
>because both R5 and
>R6 will prefer the RIP route and only R2 will see the O E2 But while I
>solved the problem in the direction RIP -> OPSF, now I have create the
>same potential problem in the opposite direction; so, if R2 were to
>redistribute its loopback as connected, I am exactly in the same
>situation as I was at the beginning but in a mirrored form. I have not
>solved the problem but just thrown in over the fence !
>
>I think that the only way out here is to increase the admin distance
>only of specific selected routes when redistributed; in this case only
>170.1.7.7 shold be changed from O E2 [110/20] to O E2 [121/20]
>
>Am I completely out of track?
>PS: sorry for the long post!
>
>
>~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> _____ R5 _|
> / | rip
> / |
> / |
>R2(ospf) |--- R7 - lo0 170.1.7.7
> \ |
> \ |
> \_____ R6 _ |
>
>
>~~~~~~~~
>
>hostname R2
>!
>interface Serial1/0
> no ip address
> encapsulation frame-relay
> serial restart-delay 0
> no frame-relay inverse-arp
>!
>interface Serial1/0.5 point-to-point
> ip address 170.1.100.9 255.255.255.252
> frame-relay interface-dlci 205
>!
>interface Serial1/0.6 point-to-point
> ip address 170.1.100.13 255.255.255.252
> frame-relay interface-dlci 206
>!
>router ospf 1
> log-adjacency-changes
> network 170.1.100.0 0.0.0.255 area 0
>
>~~~~~~~~
>
>hostname R5
>!
>interface FastEthernet0/0
> ip address 170.1.200.5 255.255.255.224
> duplex full
>!
>interface Serial1/0
> no ip address
> encapsulation frame-relay
> serial restart-delay 0
> no frame-relay inverse-arp
>!
>interface Serial1/0.1 point-to-point
> ip address 170.1.100.10 255.255.255.252
> frame-relay interface-dlci 502
>!
>router ospf 1
> log-adjacency-changes
> redistribute rip subnets route-map RO
> network 170.1.100.0 0.0.0.255 area 0
>!
>router rip
> version 2
> redistribute ospf 1 metric 2 route-map OR
> passive-interface default
> no passive-interface FastEthernet0/0
> network 170.1.0.0
> no auto-summary
>!
>route-map RO deny 10
> match tag 96 115 116 125 126
>!
>route-map RO permit 20
> set tag 125
>!
>route-map OR deny 10
> match tag 96 115 116 125 126
>!
>route-map OR permit 20
> set tag 115
>
>~~~~~~~~~~
>
>hostname R6
>!
>interface FastEthernet0/0
> ip address 170.1.200.6 255.255.255.224
> duplex full
>!
>interface Serial1/0
> no ip address
> encapsulation frame-relay
> serial restart-delay 0
> no frame-relay inverse-arp
>!
>interface Serial1/0.1 point-to-point
> ip address 170.1.100.14 255.255.255.252
> frame-relay interface-dlci 602
>!
>router ospf 1
> log-adjacency-changes
> redistribute rip subnets route-map FROM-RIP
> network 170.1.100.0 0.0.0.255 area 0
>!
>router rip
> version 2
> redistribute ospf 1 metric 2 route-map FROM-OSPF
> passive-interface default
> no passive-interface FastEthernet0/0
> network 170.1.0.0
> no auto-summary
>!
>no ip http server
>no ip http secure-server
>!
>!
>!
>logging alarm informational
>!
>!
>!
>route-map FROM-OSPF deny 10
> match tag 96 115 116 125 126
>!
>route-map FROM-OSPF permit 20
> set tag 116
>!
>route-map FROM-RIP deny 10
> match tag 96 115 116 125 126
>!
>route-map FROM-RIP permit 20
> set tag 126
>!
>~~~~~~~~~
>
>hostname R7
>!
>interface Loopback0
> ip address 170.1.7.7 255.255.255.255
>!
>interface FastEthernet0/0
> ip address 170.1.200.7 255.255.255.224
> duplex full
>!
>router rip
> version 2
> network 170.1.0.0
> no auto-summary
>!
>~~~~~~~~~~~
>R5#debug ip routing
>IP routing debugging is on
>R5(config-router)#passive-interface s1/0.1 R5(config-router)# *Aug 30
>21:07:49.147: %OSPF-5-ADJCHG: Process 1, Nbr 170.1.100.13 on
>Serial1/0.1 from FULL to DOWN, Neighbor Down: Interface down or
>detached *Aug 30 21:07:54.651: RT: del 170.1.100.12/30 via 170.1.100.9,
>ospf metric [110/128] *Aug 30 21:07:54.655: RT: delete subnet route to
>170.1.100.12/30 *Aug 30 21:07:54.659: RT: NET-RED 170.1.100.12/30 *Aug
>30 21:07:54.667: RT: del 170.1.7.7/32 via 170.1.100.9, ospf metric
>[110/20] *Aug 30 21:07:54.671: RT: delete subnet route to 170.1.7.7/32
>*Aug 30 21:07:54.675: RT: NET-RED 170.1.7.7/32 R5(config-router)#
>R5(config-router)# *Aug 30 21:08:07.395: RT: add 170.1.100.12/30 via
>170.1.200.6, rip metric [120/1] *Aug 30 21:08:07.399: RT: NET-RED
>170.1.100.12/30
>R5(config-router)#no passive-interface s1/0.1 <<<<<<<<<<< let's the
show
>begin !
>R5(config-router)#
>*Aug 30 21:08:18.071: %OSPF-5-ADJCHG: Process 1, Nbr 170.1.100.13 on
>Serial1/0.1 from LOADING to FULL, Loading Done *Aug 30 21:08:18.363:
>RT: add 170.1.7.7/32 via 170.1.200.7, rip metric [120/1] *Aug 30
>21:08:18.367: RT: NET-RED 170.1.7.7/32 *Aug 30 21:08:33.111: RT: closer
>admin distance for 170.1.100.12, flushing
>1
>routes
>*Aug 30 21:08:33.115: RT: NET-RED 170.1.100.12/30 *Aug 30 21:08:33.119:
>RT: add 170.1.100.12/30 via 170.1.100.9, ospf metric [110/128] *Aug 30
>21:08:33.123: RT: NET-RED 170.1.100.12/30 *Aug 30 21:08:33.127: RT:
>closer admin distance for 170.1.7.7, flushing 1 routes *Aug 30
>21:08:33.127: RT: NET-RED 170.1.7.7/32 *Aug 30 21:08:33.127: RT: add
>170.1.7.7/32 via 170.1.100.9, ospf metric [110/20] *Aug 30
>21:08:33.127: RT: NET-RED 170.1.7.7/32 *Aug 30 21:08:33.279: RT: del
>170.1.7.7/32 via 170.1.100.9, ospf metric [110/20] *Aug 30
>21:08:33.279: RT: delete subnet route to 170.1.7.7/32 *Aug 30
>21:08:33.279: RT: NET-RED 170.1.7.7/32 *Aug 30 21:08:45.515: RT: add
>170.1.7.7/32 via 170.1.200.7, rip metric [120/1] *Aug 30 21:08:45.519:
>RT: NET-RED 170.1.7.7/32 *Aug 30 21:08:45.615: RT: closer admin
>distance for 170.1.7.7, flushing 1 routes *Aug 30 21:08:45.615: RT:
>NET-RED 170.1.7.7/32 *Aug 30 21:08:45.615: RT: add 170.1.7.7/32 via
>170.1.100.9, ospf metric [110/20] *Aug 30 21:08:45.619: RT: NET-RED
>170.1.7.7/32 *Aug 30 21:08:50.751: RT: del 170.1.7.7/32 via
>170.1.100.9, ospf metric [110/20] *Aug 30 21:08:50.751: RT: delete
>subnet route to 170.1.7.7/32 *Aug 30 21:08:50.751: RT: NET-RED
>170.1.7.7/32 *Aug 30 21:09:14.455: RT: add 170.1.7.7/32 via
>170.1.200.7, rip metric [120/1] *Aug 30 21:09:14.459: RT: NET-RED
>170.1.7.7/32 *Aug 30 21:09:14.599: RT: closer admin distance for
>170.1.7.7, flushing 1 routes *Aug 30 21:09:14.603: RT: NET-RED
>170.1.7.7/32 *Aug 30 21:09:14.607: RT: add 170.1.7.7/32 via
>170.1.100.9, ospf metric [110/20] *Aug 30 21:09:14.611: RT: NET-RED
>170.1.7.7/32 *Aug 30 21:09:19.699: RT: del 170.1.7.7/32 via
>170.1.100.9, ospf metric [110/20] *Aug 30 21:09:19.699: RT: delete
>subnet route to 170.1.7.7/32 *Aug 30 21:09:19.699: RT: NET-RED
>170.1.7.7/32 *Aug 30 21:09:43.395: RT: add 170.1.7.7/32 via
>170.1.200.7, rip metric [120/1] *Aug 30 21:09:43.399: RT: NET-RED
>170.1.7.7/32 *Aug 30 21:09:43.527: RT: closer admin distance for
>170.1.7.7, flushing 1 routes *Aug 30 21:09:43.531: RT: NET-RED
>170.1.7.7/32 *Aug 30 21:09:43.535: RT: add 170.1.7.7/32 via
>170.1.100.9, ospf metric [110/20] *Aug 30 21:09:43.539: RT: NET-RED
>170.1.7.7/32
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Oct 06 2007 - 12:01:09 ART