From: Greg Wendel (gwendel@gmail.com)
Date: Tue Sep 04 2007 - 14:22:32 ART
There are interesting discussions on this in the archives, but I am pretty
sure the general consensus is that there is no way to get this information.
On 9/4/07, Cecil Wilson <Cecil.Wilson@flextronics.com> wrote:
>
> 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
>
> cecil.wilson@flextronics.com
>
>
>
>
>
> -----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
>
>
>
> _________________________________________________________________
>
> Get Cultured With Arts & Culture Festivals On Live Maps
>
> http://local.live.com/?mkt=en-ca&v=2&cid=A6D6BDB4586E357F!2010&encType=1
>
> &sty
>
> le=h&FORM=SERNEP
>
>
>
> _______________________________________________________________________
>
> Subscription information may be found at:
>
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
> _______________________________________________________________________
>
> Subscription information may be found at:
>
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
> Legal Disclaimer:
>
> The information contained in this message may be privileged and
> confidential. It is intended to be read only by the individual or entity to
> whom it is addressed or by their designee. If the reader of this message is
> not the intended recipient, you are on notice that any distribution of this
> message, in any form, is strictly prohibited. If you have received this
> message in error, please immediately notify the sender and delete or destroy
> any copy of this message
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
-- Gregory Wendel Springfield VA, 22153
This archive was generated by hypermail 2.1.4 : Sat Oct 06 2007 - 12:01:09 ART